Re: [PATCH] nextfd(2)

From: KOSAKI Motohiro <kosaki.motohiro@gmail.com>
To: Ulrich Drepper <drepper@gmail.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@gmail.com>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	akpm@linux-foundation.org, viro@zeniv.linux.org.uk,
	torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] nextfd(2)
Date: Wed, 04 Apr 2012 11:08:22 -0700	[thread overview]
Message-ID: <4F7C8E16.2070706@gmail.com> (raw)
In-Reply-To: <CAOPLpQdZc9m5ZpGgJtPBEvJUqeaqRneUkQx5NgXiXhvtXctDrg@mail.gmail.com>

(4/4/12 10:49 AM), Ulrich Drepper wrote:
> On Wed, Apr 4, 2012 at 13:07, KOSAKI Motohiro<kosaki.motohiro@gmail.com>  wrote:
>> Umm... I'm sorry. I haven't catch why OOM is related topic. Could you please
>> elaborate more?
>
> With fork you always have some copy-on-write (and worse for
> overcommit) just to then execute exec.  With a real spawn
> implementation you wouldn't have that.  A big problem if you, for
> instance, have to spawn a small helper from a gigantic process.

Ah, ok. I agree posix_spawn() has a chance to aim more momemory efficiency
than fork-exec. But in this purpose, vfork may be enough useful and be widely
accepted from userland folks.

Example, some daemon has a following patten,
  1. fork
  2. change /proc/<pid>/oom_adj
  3. exec

That's said, when adding linux specific knob, we need to add new posix_spawn flags
if we really need (or want) to replaces all userland. this seems very hard and doubtful
worth to me.

Ahh, note. I'm not against to implement posix_spawn() into the kernel. I only argue spawn()
can solve closefrom issue.