From: Torsten Duwe <duwe@lst.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>, Kevin Hao <haokexin@gmail.com>,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [RFC] powerpc: use ticket spin lock for !CONFIG_PPC_SPLPAR
Date: Thu, 12 Mar 2015 16:24:10 +0100 [thread overview]
Message-ID: <20150312152410.GA12372@lst.de> (raw)
In-Reply-To: <1426158807.17565.131.camel@kernel.crashing.org>
On Thu, Mar 12, 2015 at 10:13:27PM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2015-03-12 at 18:55 +0800, Kevin Hao wrote:
> > I know Torsten Duwe has tried to add the ticket spinlock for powerpc
> > one year ago [1]. But it make no progress due to the conflict between
OMG, time flies.
> > PPC_SPLPAR and lockref. We still don't find a better way to handle
> > this. But instead of waiting forever for a perfect solution, can't we
> > just use the ticket spinlock for the !CONFIG_PPC_SPLPAR?
I was actually thinking about squeezing it all (incl. lockref) into 64 bits,
or making it a bit larger, keeping the holder outside the cache line, or ...
Then priorities shifted.
> I would do the ifdef'ing differently, something like
>
> CONFIG_PPC_HAS_LOCK_OWNER
>
> CONFIG_PPC_TICKET_LOCKS depends on !PPC_HAS_LOCK_OWNER
>
> and use these two in the code... with SPLPAR select'ing HAS_LOCK_OWNER
Or avoid ifdef'ing and give pseries its own, platform-specific lock implementation?
It's more work in the build framework but clearer in the C source. Just a though.
But generally, which platforms would benefit most from this change?
I must admit my access to hardware variety is somewhat limited ;-)
Torsten
next prev parent reply other threads:[~2015-03-12 15:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-12 10:55 [RFC] powerpc: use ticket spin lock for !CONFIG_PPC_SPLPAR Kevin Hao
2015-03-12 11:13 ` Benjamin Herrenschmidt
2015-03-12 15:24 ` Torsten Duwe [this message]
2015-03-13 6:09 ` Kevin Hao
2015-03-13 7:07 ` Benjamin Herrenschmidt
2015-03-13 5:59 ` Kevin Hao
2015-03-13 7:09 ` Michael Ellerman
2015-03-13 7:14 ` Benjamin Herrenschmidt
2015-03-16 0:25 ` Sam Bobroff
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=20150312152410.GA12372@lst.de \
--to=duwe@lst.de \
--cc=benh@kernel.crashing.org \
--cc=haokexin@gmail.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=paulus@samba.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.