From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Mike Galbraith <efault@gmx.de>
Subject: Re: [PATCH 5/5] ipc/sem.c: alternatives to preempt_disable()
Date: Tue, 24 Jan 2012 15:51:45 +0100 [thread overview]
Message-ID: <1327416705.2446.58.camel@twins> (raw)
In-Reply-To: <1318684920-2033-1-git-send-email-manfred@colorfullife.com>
On Sat, 2011-10-15 at 15:22 +0200, Manfred Spraul wrote:
> ipc/sem.c uses a custom wakeup scheme that relies on preempt_disable().
> On -RT, this causes increased latencies and debug warnings.
>
> The patch adds two additional schemes:
> - one built around a completion - could be better for -RT kernels
> - one built around a spinlock - unfortunately it's broken
> - and the current one
>
> Mike, Peter: Would the completion work on -rt?
>
> My preferred solution would be the spinlock implementation:
> RT would use premptible spinlocks, mainline normal spinlocks.
> Thus both get the optimal implementation without any special code in
> ipc/sem.c.
> Unfortunately, I don't see how it could be fixed.
Sorry, I was convinced I replied to this, but I cannot actually find
anything in my send folder or elsewhere. Thanks for poking Andrew.
Yes I think it should work, and I'm afraid I have to agree with not
being able to make the spinlock thing work properly. Even if you were to
use arch_spin_* primitives you can still run into the 256 limit --
although not from the preempt_count in that case. Nor would arch_spin_
do what we need on -rt.
next prev parent reply other threads:[~2012-01-24 14:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-15 13:22 [PATCH 5/5] ipc/sem.c: alternatives to preempt_disable() Manfred Spraul
2012-01-24 14:51 ` Peter Zijlstra [this message]
2012-01-28 19:01 ` Manfred Spraul
2012-03-28 23:06 ` Andrew Morton
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=1327416705.2446.58.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=akpm@google.com \
--cc=efault@gmx.de \
--cc=linux-kernel@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 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.