Re: [RFC] powerpc: use ticket spin lock for !CONFIG_PPC_SPLPAR

[Sam Bobroff <sam.bobroff@au1.ibm.com>]

On 13/03/15 18:14, Benjamin Herrenschmidt wrote:
> On Fri, 2015-03-13 at 18:09 +1100, Michael Ellerman wrote:
>> 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?

Confer certainly helps in some situations, although I think it will be
strongly workload and configuration dependent and I haven't tried to do
much realistic testing.

Also, being able to use confer depends on both knowing the lock owner
and also that the lock owner's VCPU is not currently running (which is
done via the yield count, which is also part of the lock token at the
moment). With just the yield count we could still use an undirected
confer (which might be almost as good as a directed one), but without it
we would have to drop it entirely.

>> 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?
> 
> Another possibility would be to change the order of the count and the
> lock in lockref and defined it to be packed. That might allow us to have
> our lock contain the ticket first and the count next and "fit" ...
> 
>> cheers
>>
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>