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 >
