Hi Valentin, On Wednesday 12 Feb 2020 at 09:30:34 (+0000), Valentin Schneider wrote: > On 11/02/2020 18:45, Ionela Voinescu wrote: > > From: Valentin Schneider <valentin.schneider@xxxxxxx> > > > > Using an arch timer with a frequency of less than 1MHz can result in an > > incorrect functionality of the system which assumes a reasonable rate. > > > > One example is the use of activity monitors for frequency invariance > > which uses the rate of the arch timer as the known rate of the constant > > cycle counter in computing its ratio compared to the maximum frequency > > of a CPU. For arch timer frequencies less than 1MHz this ratio could > > end up being 0 which is an invalid value for its use. > > > > I'm being pedantic here (as usual), but I'd contrast this a bit more. The > activity monitor code checks by itself that the ratio doesn't end up being > 0, which is why we don't slam the brakes if the arch timer freq is < 1MHz. > > It's just a CNTFRQ sanity check that goes a bit beyond the 0 value check, > IMO. > I agree, but this part was just given as an example of functionality that relies on a reasonable arch timer rate. The AMU code checks for the ratio not to be 0 so it does not end up breaking frequency invariance. But if the ratio does end up being 0 due to the value of arch_time_rate, we bypass the use of activity monitors which I'd argue it's incorrect functionality by disabling a potential better source of information for frequency invariance. But I can rewrite this part for more clarity. > > Therefore, warn if the arch timer rate is below 1MHz which contravenes > > the recommended architecture interval of 1 to 50MHz. > > > > Signed-off-by: Ionela Voinescu <ionela.voinescu@xxxxxxx> > > Cc: Mark Rutland <mark.rutland@xxxxxxx> > > Cc: Marc Zyngier <maz@xxxxxxxxxx> > > ISTR something somewhere that says the first signoff should be that of the > author of the patch, and seeing as I just provided an untested diff that > ought to be you :) Will do! Thanks, Ionela.
