Re: [rfc/patch] mm/slub: restore/expand unfreeze_partials() local exclusion scope

[Vlastimil Babka]

On 7/25/21 5:02 PM, Mike Galbraith wrote:
> On Sun, 2021-07-25 at 16:16 +0200, Vlastimil Babka wrote:
>> On 7/25/21 4:09 PM, Mike Galbraith wrote:
>>> On Sat, 2021-07-24 at 00:39 +0200, Vlastimil Babka wrote:
>>>>
>>>> If not, then I would expect this to work (I don't think they ever nest
>>>> in the opposite order, also lockdep should tell us instead of
>>>> -ENOBOOT?), but might be missing something...
>>>
>>> Yeah, like #ifndef CONFIG_PREMPT_RT at the bottom of the loop that our
>>> useless damn eyeballs auto-correct instead of reporting :)
>>
>> Well doh, good catch.
> 
> I never did see it.  I got sick of saying "but but but", and did make
> mm/slub.i, which made it glow.

Glad you did.

>> Hope fixing that helps then?
> 
> Yeah, though RT should perhaps be pinned across release/re-acquire?

Probably not necessary, this_cpu_cmpxchg() will effectively recognize
being moved to a different CPU.
Might also move __unfreeze_partials() out of the whole loop to avoid the
relock. Yeah that should be better.

> Actually, local locks should rediscover the recursion handling skills
> they long had so such RT specific hole poking isn't necessary.  There
> previously would have been no ifdef+typo there for eyeballs to miss and
> miss and miss.

Hm, now I'm realizing that local_lock() on !RT is just
preempt_disable(), i.e. equivalent to get_cpu_ptr(), so some of the
ifdeffery could go away?

> 	-Mike
>