-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Regarding Runtime Parameter #1217
Comments
Hi, thanks for reporting this, that should not be the case so sounds like we might have a bug somewhere. As a workaround could you try explicitly specifying the frequency of the enabled cores that you are looking for and see if that allows you to make progress? e.g.
|
Thanks for the quick response. Still does not seem to work:
With the output as below:
|
Hmm.. I see. It seems like this is happening because WA is resolving to the first cpu in the cluster and incorrectly not checking to find the first "online" cpu in the cluster. If you don't have the requirement for particular cpus and only the number online per cluster, one potential workaround may be to online the first cpu of each cluster and hopefully allow WA's resolution to function as intended.
|
Ahhhh i see, I was hoping that that wasnt the case as I would prefer having the flexibility of particular cpus |
As per [1], any attempt to configure a core's frequency will fail if the first core of the associated frequency domain is offline. Remove the assumption that the first cpu should be used when committing the change to the device to resolve this. [1] ARM-software#1217
As per [1], any attempt to configure a core's frequency will fail if the first core of the associated frequency domain is offline. Remove the assumption that the first cpu should be used when committing the change to the device to resolve this. [1] ARM-software#1217
I think I've found the problem (and a few others in the process). Would you be able to try out this [1] branch on your setup and let me know if this resolves the issue for you? [1] https://github.com/marcbonnici/workload-automation/tree/cpu_domain_fix |
Okay, so I switched branches, and i just used the setup.py and followed the installation with:
And the given version is 3.4.0.dev1+7c432d74. but the issue still seems to occur. |
Hmm.. thanks for trying that out. |
run.log
|
As per [1], any attempt to configure a core's frequency will fail if the first core of the associated frequency domain is offline. Remove the assumption that the first cpu should be used when committing the change to the device to resolve this. [1] ARM-software#1217
As per [1], any attempt to configure a core's frequency will fail if the first core of the associated frequency domain is offline. Remove the assumption that the first cpu should be used when committing the change to the device to resolve this. [1] ARM-software#1217
Thanks, would you be able to pull my branch again and see if this resolves this problem for you? |
Still seems to be happening. |
Hi Honsunhc - what happens if you try to explicitly set the frequency for each online CPU, rather than the cluster frequency? e.g
|
Right it looks like next issue here is that WA queries the device at the time it validates the input parameters and this can change before they are committed to the device. At the point the cluster I think Scotts workaround should work as it doesn't not rely on this resolution, however I've also updated my branch again to change the order the sysfile runtime parameters are set on the device so that any frequency configuration happens before we offline cpus. Would you be able to check if this one gets things working for you? |
So I tried both Scotts method and the normal cluster method, and they both work great! There was one instance using the |
Thanks for confirming, I'm glad we finally have a working setup for you. I think I might know what could cause the issue with the cluster approach but would need to look into this further so I'll keep this issue open for now as well. |
So it seems that this could be a more persistent issue. |
I think the issue here is the cluster names combined with the hotplugging and iterations, the resolution of the cpus is still being performed at the start of the run and when trying to configure the device on subsequent iterations we run into the same problem. Does using the |
Yep, using |
Ok thanks for confirming. I looks like to solve the cluster parameters in combination with hotplugging the runtime parameter mechanism would require some more invasive changes. Just to double check, are you still using my topic branch to get things working on your end rather than the upstream implementation? If so I'll look at merging those changes so we at least have a workable solution upstream as well. |
Yep, I've been using your branch rather than the upstream implementation. |
The device that I am using has three clusters as shown in the device_config below:
And if I try to change the frequency of cluster A76 when CPU4 is off, WA returns an error saying that it is not possible due to CPU4 being off even though CPU5, a cpu in the same cluster, is on:
Is there no way around this? Is it because CPU5 frequency is fixed to CPU4? Any advice is appreciated. The device is Pixel 6.
The text was updated successfully, but these errors were encountered: