Messages in this thread | | | Subject | Re: [PATCH 13/13] hrtimer: make select() and poll() use the hrtimer range feature | From | Peter Zijlstra <> | Date | Tue, 02 Sep 2008 10:22:20 +0200 |
| |
On Mon, 2008-09-01 at 16:14 -0700, Arjan van de Ven wrote: > From: Arjan van de Ven <arjan@linux.intel.com> > Subject: [PATCH] hrtimer: make select() and poll() use the hrtimer range feature > > This patch makes the select() and poll() hrtimers use the new range > feature and settings from the task struct. > > In addition, this includes the estimate_accuracy() function that Linus > posted to lkml (but with a few steps added based on experiments). > > Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> > --- > fs/select.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++- > 1 files changed, 66 insertions(+), 2 deletions(-) > > diff --git a/fs/select.c b/fs/select.c > index f6dceb5..21bf77d 100644 > --- a/fs/select.c > +++ b/fs/select.c > @@ -28,6 +28,62 @@ > > #include <asm/uaccess.h> > > + > +/* Estimate expected accuracy in ns from a timeval */ > + > +static unsigned long __estimate_accuracy(struct timespec *tv) > +{ > + /* > + * Tens of ms if we're looking at seconds, even > + * more for 10s+ sleeping > + */ > + if (tv->tv_sec) { > + /* 100 milliseconds for long sleeps */ > + if (tv->tv_sec > 10) > + return 100 * NSEC_PER_MSEC; > + > + /* > + * Tens of ms for second-granularity sleeps. This, > + * btw, is the historical Linux 100Hz timer range. > + */ > + return 10 * NSEC_PER_MSEC; > + } > + > + /* 5 msec if we're looking at 100+ milliseconds */ > + if (tv->tv_nsec > 100 * NSEC_PER_MSEC) > + return 5 * NSEC_PER_MSEC; > + > + /* A msec if we're looking at 10+ milliseconds */ > + if (tv->tv_nsec > 10 * NSEC_PER_MSEC) > + return NSEC_PER_MSEC; > + > + /* half a msec if we're looking at milliseconds */ > + if (tv->tv_nsec > NSEC_PER_MSEC) > + return NSEC_PER_MSEC/2; > + > + /* Single usecs if we're looking at microseconds */ > + if (tv->tv_nsec > NSEC_PER_USEC) > + return NSEC_PER_USEC; > + > + /* Aim for tenths of nanosecs otherwise */ > + return 10; > +}
Why not use a simple logarithmic decay to drive this estimate?
| |