linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Mike Galbraith <efault@gmx.de>,
	Thomas Gleixner <tglx@linutronix.de>,
	LKML <linux-kernel@vger.kernel.org>,
	linux-rt-users <linux-rt-users@vger.kernel.org>
Subject: Re: [PATCH -rt] ipc/sem: Rework semaphore wakeups
Date: Wed, 14 Sep 2011 21:23:33 +0200	[thread overview]
Message-ID: <1316028213.5040.41.camel@twins> (raw)
In-Reply-To: <4E70F6FD.2060709@colorfullife.com>

On Wed, 2011-09-14 at 20:48 +0200, Manfred Spraul wrote:
> On 09/14/2011 11:57 AM, Peter Zijlstra wrote:
> > Subject: ipc/sem: Rework semaphore wakeups
> > From: Peter Zijlstra<a.p.zijlstra@chello.nl>
> > Date: Tue Sep 13 15:09:40 CEST 2011
> >
> > Current sysv sems have a weird ass wakeup scheme that involves keeping
> > preemption disabled over a potential O(n^2) loop and busy waiting on
> > that on other CPUs.
> Have you checked that the patch improves the latency?
> Note that  the busy wait only happens if there is a simultaneous timeout 
> of a semtimedop() and a true wakeup.
> 
> The code does:
> 
>      spin_lock()
>      preempt_disable();
>      usually_very_simple_but_worstcase_O_2
>      spin_unlock()
>      usually_very_simple_but_worstcase_O_1
>      preempt_enable();
> 
> with your change, it becomes:
> 
>      spin_lock()
>      usually_very_simple_but_worstcase_O_2
>      usually_very_simple_but_worstcase_O_1
>      spin_unlock()
> 
> The complex ops remain unchanged, they are still under a lock.

preemptible lock (aka pi-mutex) on -rt, so no weird latencies.

> What about removing the preempt_disable?
> It's only there to cover a rare race on uniprocessor preempt systems.
> (a task is woken up simultaneously due to timeout of semtimedop() and a 
> true wakeup)
> 
> Then fix the that race - something like the attached patch [obviously 
> buggy - see the fixme]

sched_yield() is always a bug, as is it here. Its an life-lock if the
woken task is of higher priority than the waking task. A higher prio
FIFO task calling sched_yield() in a loop is just that, a loop, starving
the lower prio waker.

If you've got enough medium prio tasks around to occupy all other cpus,
you're got indefinite priority inversion, so even on smp its a problem.

But yeah its not the prettiest of solutions but it works.. see that
other patch with the wake-list stuff for something that ought to work
for both rt and mainline (except of course it doesn't actually work).

  reply	other threads:[~2011-09-14 19:23 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-10  9:12 [ANNOUNCE] 3.0.4-rt13 Thomas Gleixner
2011-09-10 14:53 ` Madovsky
2011-09-10 17:27 ` Rolando Martins
2011-09-11 10:35 ` Mike Galbraith
2011-09-11 17:01   ` Mike Galbraith
2011-09-12  7:24     ` Thomas Gleixner
2011-09-12  8:59   ` Peter Zijlstra
2011-09-12  9:05     ` Mike Galbraith
2011-09-12 13:52     ` Mike Galbraith
2011-09-12 14:53       ` Mike Galbraith
2011-09-13 13:36         ` Peter Zijlstra
2011-09-13 15:17           ` Mike Galbraith
2011-09-13 15:08         ` Peter Zijlstra
2011-09-13 15:28           ` Mike Galbraith
2011-09-13 16:13             ` Peter Zijlstra
2011-09-21 10:17               ` rt14: strace -> migrate_disable_atomic imbalance Mike Galbraith
2011-09-21 17:01                 ` Peter Zijlstra
2011-09-21 18:50                 ` Peter Zijlstra
2011-09-22  4:46                   ` Mike Galbraith
2011-09-22  6:31                     ` Peter Zijlstra
2011-09-22  8:38                 ` Peter Zijlstra
2011-09-22 10:00                 ` Peter Zijlstra
2011-09-22 11:55                   ` Mike Galbraith
2011-09-22 12:09                     ` Peter Zijlstra
2011-09-22 13:42                       ` Mike Galbraith
2011-09-22 14:05                         ` Mike Galbraith
2011-09-22 15:20                           ` Peter Zijlstra
2011-09-22 14:34                         ` Peter Zijlstra
2011-09-22 14:38                           ` Mike Galbraith
2011-09-22 14:41                             ` Mike Galbraith
2011-09-22 14:41                             ` Peter Zijlstra
2011-09-22 14:46                               ` Mike Galbraith
2011-09-22 11:31                 ` Peter Zijlstra
2011-09-22 11:46                 ` Peter Zijlstra
2011-09-22 14:52                   ` Oleg Nesterov
2011-09-22 15:13                     ` Peter Zijlstra
2011-09-14  9:57             ` [PATCH -rt] ipc/sem: Rework semaphore wakeups Peter Zijlstra
2011-09-14 13:02               ` Mike Galbraith
2011-09-14 18:48               ` Manfred Spraul
2011-09-14 19:23                 ` Peter Zijlstra [this message]
2011-09-15 17:04                   ` Manfred Spraul
2011-09-12 10:04   ` [ANNOUNCE] 3.0.4-rt13 Peter Zijlstra
2011-09-12 11:33     ` Mike Galbraith
2011-09-11 18:14 ` Mike Galbraith
2011-09-12  7:33   ` Thomas Gleixner
2011-09-12  8:05     ` Mike Galbraith
2011-09-12  8:43       ` Mike Galbraith

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=1316028213.5040.41.camel@twins \
    --to=peterz@infradead.org \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --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;
as well as URLs for NNTP newsgroup(s).