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
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.
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:
>
> [
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
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 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.481522]
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...
Yes.
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're not
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 the case
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
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
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
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
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 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 cause problems,
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 called is 1000Hz.
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 overhead - the maximum
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
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
> >
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
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, meani
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
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
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 msleep, don't fix
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
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:
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
_Anybody_ has yet
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
overhead for
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() can be called is
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:
I'd be surprised if
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, so what
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
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
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
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't
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 because he had a
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 patch because he
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
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
> > 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
>
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
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 you get
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 circles
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
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
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 the next best
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
>
> 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
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
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
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
* 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
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
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
* 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 closer to
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
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 rather see
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 hrtimers for this
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
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 most sense
66 matches
Mail list logo
