You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We don't currently mark frequency as one of the "Exposed Information" fields in our README.md, so I wouldn't take a dependency on it just yet. As for why it doesn't work, we don't currently populate that field in the ARM init files.
I'm not actually sure if there's some reason as to why, since we seem to read min/max frequency information. @malfet any idea if there's a reason we don't do this yet, or is it just a feature we need to implement at some point?
One other errant thought about this - it's unfortunate that we call this 'frequency' and not 'min_frequency' or 'max_frequency' - the latter are well-defined, but the former isn't great for us to surface. It's hard from a user perspective to appreciate that they are getting the instantaneous frequency read at the time of cpuinfo_initialize whereas the governor could have clocked the calling process up or down in the interim. Hopefully no one is relying on it at the moment, as it always returns zero, but maybe this is an opportunity to create an explicit min / max attribute and just remove 'frequency' to prevent any further usage?
if (core->processor_count == 1) {
printf("\t%" PRIu32 ": 1 processor (%" PRIu32 "), Frequency: %" PRIu64 " Hz\n",
i,
core->processor_start,
core->frequency);
}
Frequency output 0
The text was updated successfully, but these errors were encountered: