Messages in this thread | | | Subject | Re: [rfc/patch] mm/slub: restore/expand unfreeze_partials() local exclusion scope | From | Vlastimil Babka <> | Date | Sun, 25 Jul 2021 18:27:20 +0200 |
| |
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 >
| |