> BTW. my futex man page says timeout's contents "describe the maximum duration
> of the wait". Surely that should be *minimum*? Michael cc'ed.
Er, the intent of the wording is to say "futex will wait until uaddr
no longer contains val, or the timeout expires, whichever happens first".
One
BTW. my futex man page says timeout's contents describe the maximum duration
of the wait. Surely that should be *minimum*? Michael cc'ed.
Er, the intent of the wording is to say futex will wait until uaddr
no longer contains val, or the timeout expires, whichever happens first.
One option for
* Theodore Tso <[EMAIL PROTECTED]> wrote:
> What we probably need in the long-term, and not just for high
> precision wakeups, is we need a way for waiters (either in the kernel
> or in userspace) to specify a desired precision in their timers. Is
> it, "wake me up in a second, exactly", or
On Mon, Mar 12, 2007 at 10:12:14AM -0400, Theodore Tso wrote:
> On Mon, Mar 12, 2007 at 11:58:26AM +0100, Andi Kleen wrote:
> > On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
> > > On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
> > > > Ingo Molnar <[EMAIL PROTECTED]>
> This becomes especially important if we want the tickless code to
> really shine as far as power management is concerned. Unfortunately,
> the POSIX timer abstraction doesn't give this kind of flexibility
> easily, so it's going to be a while before we see significant
> userspace adoption of
On Mon, Mar 12, 2007 at 11:58:26AM +0100, Andi Kleen wrote:
> On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
> > On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
> > > Ingo Molnar <[EMAIL PROTECTED]> writes:
> > > >
> > > > the only correct approach is the use of hrtimers,
On Mon, Mar 12, 2007 at 01:21:03PM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > > > > the issue is this: your fix reduces the effects of the bug but
> > > > > it is still fundamentally incomplete because of the use of
> > > > > timer_list. So
> > > >
> > > >
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > > > the issue is this: your fix reduces the effects of the bug but
> > > > it is still fundamentally incomplete because of the use of
> > > > timer_list. So
> > >
> > > But using schedule_timeout is not a bug. Userspace timeouts are
> > > always
On Mon, Mar 12, 2007 at 12:38:29PM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > > the issue is this: your fix reduces the effects of the bug but it is
> > > still fundamentally incomplete because of the use of timer_list. So
> >
> > But using schedule_timeout is
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > the issue is this: your fix reduces the effects of the bug but it is
> > still fundamentally incomplete because of the use of timer_list. So
>
> But using schedule_timeout is not a bug. Userspace timeouts are always
> defined to be "at least".
but
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> > if HIGH_RES_TIMERS is disabled then that is what happens. But
> > frankly,
>
> disabled? I would expect it (= more wakeups) when hrtimers are
> enabled.
i mean the groupping of timer expiries happens automatically when
high-res is disabled. When
On Mon, Mar 12, 2007 at 12:19:58PM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > > even if this means more work for you (i'm sorry about that!) i'm
> > > quite sure we should take Sebastien's hrtimers based implementation
> > > of futex_wait(), and use the
> if HIGH_RES_TIMERS is disabled then that is what happens. But frankly,
disabled? I would expect it (= more wakeups) when hrtimers are enabled.
> most futex waits are without timeouts - if an application cares about
> micro-effects like that then you are much better off not using a
>
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > even if this means more work for you (i'm sorry about that!) i'm
> > quite sure we should take Sebastien's hrtimers based implementation
> > of futex_wait(), and use the nanosleep method to restart it. There's
> > no point in further tweaking the
On Mon, 2007-03-12 at 12:02 +0100, Ingo Molnar wrote:
> > Well I did convert futex_wait to an absolute timeout based version in
> > the subsequent incremental patch. I think that is OK?
>
> it still has the rounding artifacts: using timer_list there is no way to
> do a precise long sleep based
On Mon, Mar 12, 2007 at 12:02:04PM +0100, Ingo Molnar wrote:
>
> * Nick Piggin <[EMAIL PROTECTED]> wrote:
>
> > > i dont think we should try to do this. We should not and cannot do
> > > anything about all of the artifacts that comes with the use of
> > > relative timeouts and
* Andi Kleen <[EMAIL PROTECTED]> wrote:
> On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
> > On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
> > > Ingo Molnar <[EMAIL PROTECTED]> writes:
> > > >
> > > > the only correct approach is the use of hrtimers, and a patch exists
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> > i dont think we should try to do this. We should not and cannot do
> > anything about all of the artifacts that comes with the use of
> > relative timeouts and schedule_timeout().
> >
> > basically, using jiffies here (which schedule_timeout()
On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
> On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
> > Ingo Molnar <[EMAIL PROTECTED]> writes:
> > >
> > > the only correct approach is the use of hrtimers, and a patch exists for
> > > that - see below. This has been included
On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
> >
> > the only correct approach is the use of hrtimers, and a patch exists for
> > that - see below. This has been included in -rt for quite some time.
>
> But isn't that bad for power management?
Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> the only correct approach is the use of hrtimers, and a patch exists for
> that - see below. This has been included in -rt for quite some time.
But isn't that bad for power management? You'll likely get more
idle wakeups, won't you?
-Andi
-
To
On Mon, Mar 12, 2007 at 10:10:06AM +0100, Ingo Molnar wrote:
>
> * Roland McGrath <[EMAIL PROTECTED]> wrote:
>
> > I agree it should restart. But I don't think this is quite right in
> > the timeout case. It will increase the total maximum real time spent
> > arbitrarily by the amount of
On Mon, Mar 12, 2007 at 10:10:06AM +0100, Ingo Molnar wrote:
* Roland McGrath [EMAIL PROTECTED] wrote:
I agree it should restart. But I don't think this is quite right in
the timeout case. It will increase the total maximum real time spent
arbitrarily by the amount of time elapsed
Ingo Molnar [EMAIL PROTECTED] writes:
the only correct approach is the use of hrtimers, and a patch exists for
that - see below. This has been included in -rt for quite some time.
But isn't that bad for power management? You'll likely get more
idle wakeups, won't you?
-Andi
-
To
On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
the only correct approach is the use of hrtimers, and a patch exists for
that - see below. This has been included in -rt for quite some time.
But isn't that bad for power management? You'll
On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
the only correct approach is the use of hrtimers, and a patch exists for
that - see below. This has been included in -rt for
* Nick Piggin [EMAIL PROTECTED] wrote:
i dont think we should try to do this. We should not and cannot do
anything about all of the artifacts that comes with the use of
relative timeouts and schedule_timeout().
basically, using jiffies here (which schedule_timeout() does) is
* Andi Kleen [EMAIL PROTECTED] wrote:
On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
the only correct approach is the use of hrtimers, and a patch exists
for
that
On Mon, 2007-03-12 at 12:02 +0100, Ingo Molnar wrote:
Well I did convert futex_wait to an absolute timeout based version in
the subsequent incremental patch. I think that is OK?
it still has the rounding artifacts: using timer_list there is no way to
do a precise long sleep based on many
On Mon, Mar 12, 2007 at 12:02:04PM +0100, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
i dont think we should try to do this. We should not and cannot do
anything about all of the artifacts that comes with the use of
relative timeouts and schedule_timeout().
* Nick Piggin [EMAIL PROTECTED] wrote:
even if this means more work for you (i'm sorry about that!) i'm
quite sure we should take Sebastien's hrtimers based implementation
of futex_wait(), and use the nanosleep method to restart it. There's
no point in further tweaking the imprecise
if HIGH_RES_TIMERS is disabled then that is what happens. But frankly,
disabled? I would expect it (= more wakeups) when hrtimers are enabled.
most futex waits are without timeouts - if an application cares about
micro-effects like that then you are much better off not using a
per-futex
* Andi Kleen [EMAIL PROTECTED] wrote:
if HIGH_RES_TIMERS is disabled then that is what happens. But
frankly,
disabled? I would expect it (= more wakeups) when hrtimers are
enabled.
i mean the groupping of timer expiries happens automatically when
high-res is disabled. When high-res
On Mon, Mar 12, 2007 at 12:19:58PM +0100, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
even if this means more work for you (i'm sorry about that!) i'm
quite sure we should take Sebastien's hrtimers based implementation
of futex_wait(), and use the nanosleep method to
* Nick Piggin [EMAIL PROTECTED] wrote:
the issue is this: your fix reduces the effects of the bug but it is
still fundamentally incomplete because of the use of timer_list. So
But using schedule_timeout is not a bug. Userspace timeouts are always
defined to be at least.
but what you
On Mon, Mar 12, 2007 at 12:38:29PM +0100, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
the issue is this: your fix reduces the effects of the bug but it is
still fundamentally incomplete because of the use of timer_list. So
But using schedule_timeout is not a bug.
* Nick Piggin [EMAIL PROTECTED] wrote:
the issue is this: your fix reduces the effects of the bug but
it is still fundamentally incomplete because of the use of
timer_list. So
But using schedule_timeout is not a bug. Userspace timeouts are
always defined to be at least.
On Mon, Mar 12, 2007 at 01:21:03PM +0100, Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
the issue is this: your fix reduces the effects of the bug but
it is still fundamentally incomplete because of the use of
timer_list. So
But using schedule_timeout is
On Mon, Mar 12, 2007 at 11:58:26AM +0100, Andi Kleen wrote:
On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
the only correct approach is the use of hrtimers, and a patch
* Theodore Tso [EMAIL PROTECTED] wrote:
What we probably need in the long-term, and not just for high
precision wakeups, is we need a way for waiters (either in the kernel
or in userspace) to specify a desired precision in their timers. Is
it, wake me up in a second, exactly, or wake me
On Mon, Mar 12, 2007 at 10:12:14AM -0400, Theodore Tso wrote:
On Mon, Mar 12, 2007 at 11:58:26AM +0100, Andi Kleen wrote:
On Mon, Mar 12, 2007 at 12:00:20PM +0100, Thomas Gleixner wrote:
On Mon, 2007-03-12 at 12:27 +0100, Andi Kleen wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
This becomes especially important if we want the tickless code to
really shine as far as power management is concerned. Unfortunately,
the POSIX timer abstraction doesn't give this kind of flexibility
easily, so it's going to be a while before we see significant
userspace adoption of such a
42 matches
Mail list logo