[RFC] powerpc: use ticket spin lock for !CONFIG_PPC_SPLPAR
Michael Ellerman
mpe at ellerman.id.au
Fri Mar 13 18:09:01 AEDT 2015
On Thu, 2015-03-12 at 22:13 +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
> > 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?
> >
> > This is a very rough patch based on arm64 codes. I want to make sure
> > that this is acceptable before going step further. This just passed
> > build and boot test on a fsl t4240rdb board. I have done a simple
> > performance benchmark by running the following command ten times before
> > and after applying this patch:
> > ./perf bench sched messaging
> >
> > Before After
> > Averaged total time [sec]: 0.403 0.367
> >
> > So we can see a ~9% performance enhancing. This patch depends on this
> > one [2].
>
> 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
Sam was doing some work looking at CONFER, and I think so far he hasn't found
that it is much of a benefit. Hopefully he can chime in with his observations.
So the question is, should we just drop the directed CONFER and switch
wholesale to ticket locks?
We can still do CONFER on SPLPAR, we just tell the hypervisor we don't know who
to confer to.
There is still the drawback that we loose the lock owner for debugging, but
that might be worth it. And I think you can get it back with appropriate debug
options?
cheers
More information about the Linuxppc-dev
mailing list