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
Hi,
On Tue, 7 Aug 2007, Andrew Morton wrote:
> > The current msleep is fine and doesn't need any "fixing".
> > Not all the world is i386, _please_ keep hrtimer usage where it's
> > required. Simple timer should be given preference unless the higher
> > resolution is really needed, which is not
On 8/9/07, Denis Vlasenko <[EMAIL PROTECTED]> wrote:
> On 8/8/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> > You keep claiming that hrtimers are so incredibly expensive; but for
> > msleep()... which is mostly called during driver init ... I really don't
> > buy that it's really expensive. We'
On 8/8/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> You keep claiming that hrtimers are so incredibly expensive; but for
> msleep()... which is mostly called during driver init ... I really don't
> buy that it's really expensive. We're not doing this a gazilion times
> per second obviously...
On Thu, 9 Aug 2007, Andrew Morton wrote:
> This failed the Vaio test. I guess it triggered a USB bug.
>
> With this patch applied, when I hotplug my wireless mouse, the little LED
> on the mouse comes on for a second or so then goes out and no pointy clicky
> for me.
>
> It says:
>
> [ 152.48
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
On 8/8/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 08, 2007 at 03:09:14PM +0400, Manu Abraham wrote:
> > On 08 Aug 2007 13:55:28 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > > Andrew Morton <[EMAIL PROTECTED]> writes:
> > > >
> > > > I'd be surprised if there was significant overhea
On Wed, Aug 08, 2007 at 03:09:14PM +0400, Manu Abraham wrote:
> On 08 Aug 2007 13:55:28 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Andrew Morton <[EMAIL PROTECTED]> writes:
> > >
> > > I'd be surprised if there was significant overhead - the maximum frequency
> > > at which msleep() can be ca
On 08 Aug 2007 13:55:28 +0200, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
> >
> > 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 caus
Andrew Morton <[EMAIL PROTECTED]> writes:
>
> 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?
The bigger risk is probably to break drivers that rely on
On Tue, 2007-08-07 at 14:45 +0200, Roman Zippel wrote:
> Hi,
>
> On Mon, 6 Aug 2007, Arjan van de Ven wrote:
>
> > So, let me ask a direct question: What do you think is specifically
> > wrong about changing the msleep() implementation as is done here? The
> > behavior is clearly an improvement,
On Wed, 8 Aug 2007 05:47:02 +0200 (CEST) Roman Zippel <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 7 Aug 2007, Andrew Morton wrote:
>
> > On Wed, 8 Aug 2007 01:16:49 +0200 (CEST)
> > Roman Zippel <[EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > >
> > > On Tue, 7 Aug 2007, Andrew Morton wrote:
> > >
On Tue, 7 Aug 2007, Andrew Morton wrote:
> On Wed, 8 Aug 2007 01:16:49 +0200 (CEST)
> Roman Zippel <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > On Tue, 7 Aug 2007, Andrew Morton wrote:
> >
> > > I'd be surprised if there was significant overhead - the maximum frequency
> > > at which msleep()
On Wed, 8 Aug 2007 01:16:49 +0200 (CEST)
Roman Zippel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Tue, 7 Aug 2007, Andrew Morton wrote:
>
> > 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
> > overh
Hi,
On Tue, 7 Aug 2007, Andrew Morton wrote:
> 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?
>
>
_Anybody_ has yet to answer what's wrong with add
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=
Hi,
On Mon, 6 Aug 2007, Arjan van de Ven wrote:
> So, let me ask a direct question: What do you think is specifically
> wrong about changing the msleep() implementation as is done here? The
> behavior is clearly an improvement, so what is your objection on the
> flipside?
Again, we have two diff
Hi Arjan,
On 8/6/07, Arjan van de Ven <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-08-06 at 12:03 +0200, Roman Zippel wrote:
> > Hi,
> >
> > On Sun, 5 Aug 2007, Arjan van de Ven wrote:
> >
> > > > There's no problem to provide a high resolution sleep, but there is also
> > > > no reason to mess with
On Mon, 2007-08-06 at 12:03 +0200, Roman Zippel wrote:
> Hi,
>
> On Sun, 5 Aug 2007, Arjan van de Ven wrote:
>
> > > There's no problem to provide a high resolution sleep, but there is also
> > > no reason to mess with msleep, don't fix what ain't broken...
> >
> > John Corbet provided the patc
On 8/6/07, Roman Zippel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Sun, 5 Aug 2007, Arjan van de Ven wrote:
>
> > > There's no problem to provide a high resolution sleep, but there is also
> > > no reason to mess with msleep, don't fix what ain't broken...
> >
> > John Corbet provided the patch becaus
Hi,
On Sun, 5 Aug 2007, Arjan van de Ven wrote:
> > There's no problem to provide a high resolution sleep, but there is also
> > no reason to mess with msleep, don't fix what ain't broken...
>
> John Corbet provided the patch because he had a problem with the current
> msleep... in that it didn
On Mon, 2007-08-06 at 03:03 +0200, Roman Zippel wrote:
> There's no problem to provide a high resolution sleep, but there is also
> no reason to mess with msleep, don't fix what ain't broken...
John Corbet provided the patch because he had a problem with the current
msleep... in that it didn't p
Hi,
On Sun, 5 Aug 2007, Arjan van de Ven wrote:
> Timers are course resolution that is highly HZ-value dependent. For
> cases where you want a finer resolution, the kernel now has a way to
> provide that functionality... so why not use the quality of service this
> provides..
We're going in circ
> > because a lot of parts of the kernel think and work in milliseconds,
> > it's logical and USEFUL to at least provide an interface that works on
> > milliseconds.
>
> If the millisecond resolution is enough for these users, that means the
> current msleep will work fine for them.
except that
Hi,
On Sat, 4 Aug 2007, Arjan van de Ven wrote:
> > hr_msleep makes no sense. Why should we tie this interface to millisecond
> > resolution?
>
> because a lot of parts of the kernel think and work in milliseconds,
> it's logical and USEFUL to at least provide an interface that works on
> milli
On Sat, 2007-08-04 at 05:00 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 3 Aug 2007, Arjan van de Ven wrote:
>
> > > Actually the hrsleep() function would allow for submillisecond sleeps,
> > > which might be what some of the 450 users really want and they only use
> > > msleep(1) because it's t
Hi,
On Fri, 3 Aug 2007, Arjan van de Ven wrote:
> > Actually the hrsleep() function would allow for submillisecond sleeps,
> > which might be what some of the 450 users really want and they only use
> > msleep(1) because it's the next best thing.
> > A hrsleep() function is really what makes mos
>
> Actually the hrsleep() function would allow for submillisecond sleeps,
> which might be what some of the 450 users really want and they only use
> msleep(1) because it's the next best thing.
> A hrsleep() function is really what makes most sense from an API
> perspective.
I respectfully di
Hi,
On Fri, 3 Aug 2007, Arjan van de Ven wrote:
> On Fri, 2007-08-03 at 21:19 +0200, Roman Zippel wrote:
> > Hi,
> >
> > On Fri, 3 Aug 2007, Jonathan Corbet wrote:
> >
> > > Most comments last time were favorable. The one dissenter was Roman,
> > > who worries about the overhead of using hrtim
On Fri, 2007-08-03 at 21:19 +0200, Roman Zippel wrote:
> Hi,
>
> On Fri, 3 Aug 2007, Jonathan Corbet wrote:
>
> > 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 ra
Hi,
On Fri, 3 Aug 2007, Jonathan Corbet wrote:
> 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 mil
* Jonathan Corbet <[EMAIL PROTECTED]> wrote:
> Use hrtimers so that msleep() sleeps for the requested time
>
> Current msleep() snoozes for at least two jiffies, causing msleep(1)
> to sleep for at least 20ms on HZ=100 systems. Using hrtimers allows
> msleep() to sleep for something much clos
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
33 matches
Mail list logo
