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, 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.




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux