timer: Added usleep[_range] timer
in [Kernel]
|
Prev: math-emu: correct test for downshifting fraction in _FP_FROM_INT()
Next: drivers/media/video: Remove dead CONFIG_OLPC_X0_1
From: Arjan van de Ven on 28 Jul 2010 17:10 On 7/28/2010 1:58 PM, Andrew Morton wrote: > > My main concern is that someone will type usleep(50) and won't realise > 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? > for very low values of udelay() you're likely right.... but we could and 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.... but the opposite is true; the cpu idle code will effectively do the equivalent of udelay() if you're asking for a very short delay, so short that any power saving thing isn't giong to be worth it. ( + hitting scheduler overhead -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Patrick Pannuto on 28 Jul 2010 17:10 On 07/28/2010 01:58 PM, Andrew Morton wrote: > On Wed, 28 Jul 2010 13:47:46 -0700 > Patrick Pannuto <ppannuto(a)codeaurora.org> wrote: > >>> This is different from the patch I merged and I'm not seeing any >>> explanation for the change. >>> >>> The implementation of usleep() looks odd. The longer we sleep, the >>> greater the possible inaccuracy. A code comment which explains the >>> thinking and which warns people about the implications is needed. > > I wanna code comment! > I understand -- will do (if this even survives, which is unlikely) > My main concern is that someone will type usleep(50) and won't realise > 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. In that case, it would push me in the direction of only providing usleep_range, and thus forcing people to think about it that way; leave slack decisions to people who know what tolerances are acceptable. -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Patrick Pannuto on 28 Jul 2010 17:20 On 07/28/2010 02:04 PM, Arjan van de Ven wrote: > On 7/28/2010 1:58 PM, Andrew Morton wrote: >> >> My main concern is that someone will type usleep(50) and won't realise >> 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? >> > > for very low values of udelay() you're likely right.... but we could and > 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. > You're saying: usleep(usecs) { if (usecs <= 10) /* or some other cutoff */ return udelay (usecs) ... } ish? > now there is no such thing as a "low power udelay", not really anyway.... > > but the opposite is true; the cpu idle code will effectively do the > equivalent of udelay() if you're asking for a very short delay, so > short that any power saving thing isn't giong to be worth it. ( + > hitting scheduler overhead > > I think the cpu idle code covers you in the case where there's nothing else to do, but if schedule tries to let something else run and then is almost immediately interrupted, this is probably a net loss / BadThing. I have no idea what an appropriate cutoff for this would be, I found two dated (2007) papers discussing the overhead of a context switch: http://www.cs.rochester.edu/u/cli/research/switch.pdf IBM eServer, dual 2.0GHz Pentium Xeon; 512 KB L2, cache line 128B Linux 2.6.17, RHEL 9, gcc 3.2.2 (-O0) 3.8 us / context switch http://delivery.acm.org/10.1145/1290000/1281703/a3-david.pdf ARMv5, ARM926EJ-S on an OMAP1610 (set to 120MHz clock) Linux 2.6.20-rc5-omap1 48 us / context switch but nothing more recent on a quick search. Any thoughts on how to determine an appropriate cutoff? -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Arjan van de Ven on 28 Jul 2010 17:30 On 7/28/2010 2:22 PM, Andrew Morton wrote: > On Wed, 28 Jul 2010 14:04:47 -0700 > Arjan van de Ven<arjan(a)linux.intel.com> wrote: > > >> On 7/28/2010 1:58 PM, Andrew Morton wrote: >> >>> My main concern is that someone will type usleep(50) and won't realise >>> 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? >>> >>> >> for very low values of udelay() you're likely right.... but we could and >> 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.... >> > Yup. I can't find any arch which tries to do anything fancy. > > x86's rep_nop() tries to save a bit of juice, doesn't it? Should we be > using that? > it doesn't save juice so much as it is a "yield to my hyperthreading brother" (there is some power saved as well potentially...) afaik we already use this in udelay() (cpu_relax is rep_nop after all) > 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. > the only real place I've seen it used (based on profiles) is in libata in the intel piix sata driver (the non-AHCI one)... and those are completly wrong, Alan Cox had patches to fix it but those somehow went nowhere -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Morton on 28 Jul 2010 17:30
On Wed, 28 Jul 2010 14:05:39 -0700 Patrick Pannuto <ppannuto(a)codeaurora.org> wrote: > On 07/28/2010 01:58 PM, Andrew Morton wrote: > > On Wed, 28 Jul 2010 13:47:46 -0700 > > Patrick Pannuto <ppannuto(a)codeaurora.org> wrote: > > > >>> This is different from the patch I merged and I'm not seeing any > >>> explanation for the change. > >>> > >>> The implementation of usleep() looks odd. The longer we sleep, the > >>> greater the possible inaccuracy. A code comment which explains the > >>> thinking and which warns people about the implications is needed. > > > > I wanna code comment! > > > > I understand -- will do (if this even survives, which is unlikely) > > > My main concern is that someone will type usleep(50) and won't realise > > 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. > > In that case, it would push me in the direction of only providing > usleep_range, and thus forcing people to think about it that way; > leave slack decisions to people who know what tolerances are acceptable. Well, I _think_ that would be a good approach. I'm 45%/55% on that one and would be interested in other opinions ;) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |