[Ksummit-2013-discuss] [ATTEND] insane cgroups, unfair rwlocks

[Li Zefan]

>> (2) unfair rwlocks
>>
>> This is connected to Srivatsa S. Bhat's proposed topic, which he
>> thoughtfully copied me in (thanks!).
>>
>> We sometimes hit issues that can be traced down to rwlock unfairness
>> (mostly with tasklist_lock); I have been taking an interest towards
>> solving these. Recently there has been more activity than usual about
>> locking schemes and I have been trying to steer people away from
>> introducing new unfair locks where possible. I'm actually not entirely
>> sure if this warrants a KS discussion (as I understand KS nowadays is
>> more about management than technical issues); however if such
>> discussions do take place at KS I would like to participate (and if
>> not, I am always interested to discuss this informally).
> 
> 
> In the kernel community, people prefer performance to fairness.
> (but I prefer to fairness.)

I don't think this is fair. Didn't we implement ticket spinlock because
the old implementation was unfair?

And we sometimes change rwlock to spinlock because the write side is
unfairly starved.

> 
> I think performance VS fairness is always a big topic which I'm also
> interesting in. What traded-off should we chose to pay?
> I hope people continue to find fairness solution which hurts
> performance very very small.
> 
> BTW, current rwsem is not unfair too, is it right?
> 

I guess you meant resem is unfair?