On Fri, 03 Aug 2007 12:37:12 -0600 Jonathan Corbet <[EMAIL PROTECTED]> wrote:
> > Here's the second (and probably final) posting of the msleep() with > hrtimers patch. The problem being addressed here is that the current > msleep() will stop for a minimum of two jiffies, meaning that, on a > HZ=100 system, msleep(1) delays for for about 20ms. In a driver with > one such delay for each of 150 or so register setting operations, the > extra time adds up to a few seconds. > > This patch addresses the situation by using hrtimers. On tickless > systems with working timers, msleep(1) now sleeps for 1ms, even with > HZ=100. > > Most comments last time were favorable. The one dissenter was Roman, > who worries about the overhead of using hrtimers for this operation; my > understanding is that he would rather see a really_msleep() function for > those who actually want millisecond resolution. I'm not sure how to > characterize what the cost could be, but it can only be buried by the > fact that every call sleeps for some number of milliseconds. On my > system, the several hundred total msleep() calls can't cause any real > overhead, and almost all happen at initialization time. I'd be surprised if there was significant overhead - the maximum frequency at which msleep() can be called is 1000Hz. We'd need an awful lot of overhead for that to cause problems, surely? <thinks he's missing something again> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
