> > I look at it in scope of GFP_ATOMIC/GFP_NOWAIT issues, i.e. inability > > to provide a memory service for contexts which are not allowed to > > sleep, RCU is part of them. Both flags used to provide such ability > > before but not anymore. > > > > Do you agree with it? > > Yes this sucks. But this is something that we likely really want to live > with. We have to explicitly _document_ that really atomic contexts in RT > cannot use the allocator. From the past discussions we've had this is > likely the most reasonable way forward because we do not really want to > encourage anybody to do something like that and there should be ways > around that. The same is btw. true also for !RT. The allocator is not > NMI safe and while we should be able to make it compatible I am not > convinced we really want to. > > Would something like this be helpful wrt documentation? > > diff --git a/include/linux/gfp.h b/include/linux/gfp.h > index 67a0774e080b..9fcd47606493 100644 > --- a/include/linux/gfp.h > +++ b/include/linux/gfp.h > @@ -238,7 +238,9 @@ struct vm_area_struct; > * %__GFP_FOO flags as necessary. > * > * %GFP_ATOMIC users can not sleep and need the allocation to succeed. A lower > - * watermark is applied to allow access to "atomic reserves" > + * watermark is applied to allow access to "atomic reserves". > + * The current implementation doesn't support NMI and other non-preemptive context > + * (e.g. raw_spin_lock). > * > * %GFP_KERNEL is typical for kernel-internal allocations. The caller requires > * %ZONE_NORMAL or a lower zone for direct access but can direct reclaim. > To me it is clear. But also above conflicting statement: <snip> %GFP_ATOMIC users can not sleep and need the allocation to succeed. A %lower <snip> should be rephrased, IMHO. -- Vlad Rezki
