Messages in this thread | | | Date | Wed, 04 Apr 2012 11:08:22 -0700 | From | KOSAKI Motohiro <> | Subject | Re: [PATCH] nextfd(2) |
| |
(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.
| |