On Thu, Aug 13, 2020 at 06:14:32PM +0200, Thomas Gleixner wrote: > Matthew Wilcox <willy@xxxxxxxxxxxxx> writes: > > On Thu, Aug 13, 2020 at 03:27:15PM +0200, Thomas Gleixner wrote: > >> And guarding it with RT is not working either because then you are back > >> to square one with the problem which triggered the discussion in the > >> first place: > >> > >> raw_spin_lock() > >> alloc() > >> if (RT && !preemptible()) <- False because RT == false > >> goto bail; > >> > >> spin_lock(&zone->lock) --> LOCKDEP complains > >> > >> So either you convince Paul not to do that or you need to do something > >> like I suggested in my other reply. > > > > I'd like to throw in the possibility that we do something like: > > > > raw_spin_lock() > > alloc() > > if (!spin_trylock(&zone->lock)) > > if (RT && !preemptible()) > > goto bail; > > spin_lock(&zone->lock); > > > > would that make us feel more comfortable about converting zone->lock to > > a raw spinlock? > > Even if that could cure that particular problem of allocations in deep > atomic context, making zone->lock raw brings back the problem of > zone->lock being held/contended for hundreds of microseconds with > interrupts disabled which is causing RT tasks to miss their deadlines by > big margins. Ah, I see. Yeah, that doesn't work. Never mind.
