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 13:21:03 +0100 [thread overview]
Message-ID: <20070312122103.GA30778@elte.hu> (raw)
In-Reply-To: <20070312115201.GI28546@wotan.suse.de>
* Nick Piggin <npiggin@suse.de> 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 are adding isnt a plain schedule_timeout(), it is a
> > restart block handling loop. And for those restart blocks that
> > relate to timeouts, we only use hrtimers. I am not making this up to
> > annoy you: take a look at all the current restart block handlers -
> > they are hrtimer based, for exactly this reason.
>
> So why do you say it is fundamentally incomplete?
because i misread your last patch :-) I thought it still has a window
for inaccuracy, but you are right: it should be at most 1 jiffy
inaccurate, no matter how many times we restart.
still ... the hrtimers patch has been submitted to lkml before yours,
and has been tested extensively, so why go the extra side-jump
prolonging the jiffies sleep method? The LTP failure has been there
since the inception of the futex code i suspect. Going this way also
enables the addressing of a more pressing need: the elimination of
glibc's forced use of relative futex timeouts.
Ingo
next prev parent reply other threads:[~2007-03-12 12:21 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
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 [this message]
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=20070312122103.GA30778@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