On Mon 10-08-20 21:25:26, Michal Hocko wrote: > On Mon 10-08-20 18:07:39, Uladzislau Rezki wrote: [...] > > The problem that i see is we can not use the page allocator from atomic > > contexts, what is our case: > > > > <snip> > > local_irq_save(flags) or preempt_disable() or raw_spinlock(); > > __get_free_page(GFP_ATOMIC); > > <snip> > > > > So if we can convert the page allocator to raw_* lock it will be appreciated, > > at least from our side, IMHO, not from RT one. But as i stated above we need > > to sort raised questions out if converting is done. > > > > What is your view? > > To me it would make more sense to support atomic allocations also for > the RT tree. Having both GFP_NOWAIT and GFP_ATOMIC which do not really > work for atomic context in RT sounds subtle and wrong. I was thinking about this some more. I still think the above would be a reasonable goal we should try to achieve. If for not other then for future maintainability (especially after the RT patchset is merged). I have tried to search for any known problems/attempts to make zone->lock raw but couldn't find anything. Maybe somebody more involved in RT world have something to say about that. Anyway, if the zone->lock is not a good fit for raw_spin_lock then the only way I can see forward is to detect real (RT) atomic contexts and bail out early before taking the lock in the allocator for NOWAIT/ATOMIC requests. -- Michal Hocko SUSE Labs
