Re: [Lsf-pc] [LSF/MM/BPF TOPIC] Reclamation interactions with RCU

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 04 Mar 2024, Matthew Wilcox wrote:
> On Mon, Mar 04, 2024 at 09:45:48AM +1100, NeilBrown wrote:
> > I have in mind a more explicit statement of how much waiting is
> > acceptable.
> > 
> > GFP_NOFAIL - wait indefinitely
> > GFP_KILLABLE - wait indefinitely unless fatal signal is pending.
> > GFP_RETRY - may retry but deadlock, though unlikely, is possible.  So
> >             don't wait indefinitely.  May abort more quickly if fatal
> >             signal is pending.
> > GFP_NO_RETRY - only try things once.  This may sleep, but will give up
> >             fairly quickly.  Either deadlock is a significant
> >             possibility, or alternate strategy is fairly cheap.
> > GFP_ATOMIC - don't sleep - same as current.
> 
> I don't think these should be GFP flags.  Rather, these should be
> context flags (and indeed, they're mutually exclusive, so this is a
> small integer to represent where we are on the spectrum).  That is
> we want code to do
> 
> void *alloc_foo(void)
> {
> 	return init_foo(kmalloc(256, GFP_MOVABLE));
> }
> 
> void submit_foo(void)
> {
> 	spin_lock(&submit_lock);
> 	flags = memalloc_set_atomic();
> 	__submit_foo(alloc_foo());
> 	memalloc_restore_flags(flags);
> 	spin_unlock(&submit_lock);
> }
> 
> struct foo *prealloc_foo(void)
> {
> 	return alloc_foo();
> }
> 
> ... for various degrees of complexity.  That is, the _location_ of memory
> is allocation site knowledge, but how hard to try is _path_ dependent,
> and not known at the allocation site because it doesn't know what locks
> are held.
> 

I'm not convinced.  While there is a path dependency there is also
location dependency.
The code at the call-site determines what happens in response to
failure.
For GFP_NOFAIL, failure is not possible.  We cannot allow context to
turn NOFAIL into NOSLEEP because context cannot add error handling.

Consider mempool_alloc().  That requests a NORETRY allocation because
there is an easy fall-back.  Is that a location dependency or a path
dependency?  I would say it is location.  Of course a location is just a
very short path so it is a path dependency too - but is that perspective
really helpful?

Certainly I could accept a GFP_WHATEVER which uses NOSLEEP if path
context demands that, and NO_OOM otherwise.

Thanks,
NeilBrown




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux