[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