> 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 optio
* 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]> 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 suc
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, an
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
* 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 de
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 hi
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 nanosle
> 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-fute
* 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 im
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 o
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(
* 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() does)
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 i
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? Yo
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 unsubs
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
included in -rt for quite some time.
so i'd suggest for Nick to add restart processing ontop of this patch:
hrtimers use absolute timeouts and hence there are neither rounding nor
signal processing delay artifacts.
Ingo
-->
From: S�bastien Dugu� <[EMAIL PROTECTED
22 matches
Mail list logo
