All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pierre Peiffer <pierre.peiffer@bull.net>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Linus Torvalds <torvalds@osdl.org>,
	LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@osdl.org>,
	Ulrich Drepper <drepper@redhat.com>,
	Jakub Jelinek <jakub@redhat.com>
Subject: Re: [PATCH] Futex: Revert the non-functional REQUEUE_PI
Date: Mon, 18 Jun 2007 12:58:26 +0200	[thread overview]
Message-ID: <46766552.3080803@bull.net> (raw)
In-Reply-To: <1182107470.8176.455.camel@chaos>

Thomas Gleixner wrote :
> Patch d0aa7a70bf03b9de9e995ab272293be1f7937822 titled 
> 
> "futex_requeue_pi optimization"
> 
> introduced user space visible changes to the futex syscall.
> 
> The patch is non-functional and there is no way to fix it proper before
> the 2.6.22 release. 
> 
> The breakage report ( http://lkml.org/lkml/2007/5/12/17 ) went
> unanswered,

Sorry, but I passed lot of time on this last year without any answers or 
comments from the community when I have sent my patches.
Now I'm working on something else and I can't spent more time on this for now... 
Futexes are so complex that it is always difficult to investigate a problem in 
only one or two hours...

> and unfortunately it turned out that the concept is not
> feasible at all. 

Without robust futex, the concept works well, and the performance gain has been 
proven.

It violates the rtmutex semantics badly by introducing
> a virtual owner, which hacks around the coupling of the user-space
> pi_futex and the kernel internal rt_mutex representation.

What you call a hack, is for me a design point. And if this is a hack, then I 
think that we can say that futexes are based on a series of hacks...
But, okay, this is not very constructive, so...

Ulrich Drepper wrote :
 >
 > Indeed.  A lot more discussion is needed to handle this correctly.  No
 > committed code in glibc so far uses the function so removal is no problem.

Once again, it's a pity that people didn't spent time to comment on this when I 
was working on this.
Now, the work will probably just be lost...

-- 
Pierre

  parent reply	other threads:[~2007-06-18 10:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-17 19:11 [PATCH] Futex: Revert the non-functional REQUEUE_PI Thomas Gleixner
2007-06-17 19:21 ` Ulrich Drepper
2007-06-18 10:58 ` Pierre Peiffer [this message]
2007-06-18 14:12   ` Ulrich Drepper

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=46766552.3080803@bull.net \
    --to=pierre.peiffer@bull.net \
    --cc=akpm@osdl.org \
    --cc=drepper@redhat.com \
    --cc=jakub@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    --cc=torvalds@osdl.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.