From: Ingo Molnar <mingo@elte.hu>
To: Nick Piggin <npiggin@suse.de>
Cc: Roland McGrath <roland@redhat.com>,
akpm@linux-foundation.org, mm-commits@vger.kernel.org,
drepper@redhat.com, oleg@tv-sign.ru, sebastien.dugue@bull.net,
linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [patch] change futex_wait() to hrtimers
Date: Mon, 12 Mar 2007 12:02:04 +0100 [thread overview]
Message-ID: <20070312110204.GD2231@elte.hu> (raw)
In-Reply-To: <20070312091628.GE28546@wotan.suse.de>
* Nick Piggin <npiggin@suse.de> 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
> > /fundamentally/ imprecise. If you get many interrupts, rounding
> > errors sum up - and there's nothing we can do about it!
>
> 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 small sleeps.
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 approach: whenever some timeout
needs to be restarted, it's a candidate for hrtimers.
until then, glibc already handles timeouts and restarts it manually.
Ingo
next prev parent reply other threads:[~2007-03-12 11:03 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200703110814.l2B8EaI1007615@shell0.pdx.osdl.net>
[not found] ` <20070312011259.3834A1801C4@magilla.sf.frob.com>
2007-03-12 9:10 ` [patch] change futex_wait() to hrtimers Ingo Molnar
2007-03-12 9:16 ` Nick Piggin
2007-03-12 11:02 ` Ingo Molnar [this message]
2007-03-12 11:13 ` Nick Piggin
2007-03-12 11:19 ` Ingo Molnar
2007-03-12 11:29 ` Nick Piggin
2007-03-12 11:38 ` Ingo Molnar
2007-03-12 11:52 ` Nick Piggin
2007-03-12 12:21 ` Ingo Molnar
2007-03-12 12:36 ` Nick Piggin
2007-03-12 11:19 ` Thomas Gleixner
2007-03-12 11:27 ` Andi Kleen
2007-03-12 11:00 ` Thomas Gleixner
2007-03-12 10:58 ` Andi Kleen
2007-03-12 11:04 ` Ingo Molnar
2007-03-12 11:20 ` Andi Kleen
2007-03-12 11:28 ` Ingo Molnar
2007-03-12 14:12 ` Theodore Tso
2007-03-12 14:22 ` Andi Kleen
2007-03-12 14:31 ` Ingo Molnar
2007-03-12 14:32 ` Nick Piggin
2007-03-15 0:03 linux
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070312110204.GD2231@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=drepper@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mm-commits@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=oleg@tv-sign.ru \
--cc=roland@redhat.com \
--cc=sebastien.dugue@bull.net \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox