On Wed, Sep 30, 2020 at 1:22 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > I think documenting is useful. > > > > > > > > Could it be more explicit in what the issue is? Something like: > > > > > > > > * Even with GFP_ATOMIC, calls to the allocator can sleep on PREEMPT_RT > > > > systems. Therefore, the current low-level allocator implementation does not > > > > support being called from special contexts that are atomic on RT - such as > > > > NMI and raw_spin_lock. Due to these constraints and considering calling code > > > > usually has no control over the PREEMPT_RT configuration, callers of the > > > > allocator should avoid calling the allocator from these cotnexts even in > > > > non-RT systems. > > > > > > I do not mind documenting RT specific behavior but as mentioned in other > > > reply, this should likely go via RT tree for now. There is likely more > > > to clarify about atomicity for PREEMPT_RT. > > > > I am sorry, I did not understand what you meant by something missing > > in Linus Tree. CONFIG_PREEMPT_RT is there. > > OK, I was not aware we already CONFIG_PREEMPT_RT in the three. There is > still a lot from the RT patchset including sleeping spin locks that make > a real difference. Or maybe I haven't checked properly. > > > Could you clarify? Also the CONFIG_PREEMPT_RT is the only thing > > driving this requirement for GFP_ATOMIC right? Or are there non-RT > > reasons why GFP_ATOMIC allocation cannot be done from > > NMI/raw_spin_lock ? > > I have already sent a clarification patch [1]. NMI is not supported > regardless of the preemption mode. Hope this clarifies it a bit. > > [1] http://lkml.kernel.org/r/20200929123010.5137-1-mhocko@xxxxxxxxxx That works for me. Thanks, - Joel
