On Wed, 28 Jul 2010 14:04:47 -0700
Arjan van de Ven<arjan@xxxxxxxxxxxxxxx> wrote:
On 7/28/2010 1:58 PM, Andrew Morton wrote:Yup. I can't find any arch which tries to do anything fancy.
My main concern is that someone will type usleep(50) and won't realisefor very low values of udelay() you're likely right.... but we could and
that it goes and sleeps for 100 usecs and their code gets slow as a
result. This sort of thing takes *years* to discover and fix. If we'd
forced them to type usleep_range() instead, it would never have happened.
Another question: what is the typical overhead of a usleep()? IOW, at
what delay value does it make more sense to use udelay()? Another way
of asking that would be "how long does a usleep(1) take"? If it
reliably consumes 2us CPU time then we shouldn't do it.
But it's not just CPU time, is it? A smart udelay() should put the CPU
into a lower power state, so a udelay(3) might consume less energy than
a usleep(2), because the usleep() does much more work in schedule() and
friends?
should catch that inside usleep imo and fall back to a udelay
it'll likely be 10 usec or so where we'd cut off.
now there is no such thing as a "low power udelay", not really anyway....
x86's rep_nop() tries to save a bit of juice, doesn't it? Should we be
using that?
Because we use udelay() in many places - it wouldn't surprise me if
some people's machines were consuming significant amounts of
time/energy in there, if they have suitably broken hardware or drivers.