Messages in this thread | | | Date | Mon, 7 Jul 2014 16:52:35 -0700 | Subject | Re: fallout of 16K stacks | From | Linus Torvalds <> |
| |
On Mon, Jul 7, 2014 at 4:04 PM, Andi Kleen <andi@firstfloor.org> wrote: >> >> As in ENOMEM or does something worse happen? > > EAGAIN, then the workload stops. For an overnight stress > test that's pretty catastrophic. It may have killed some stuff > with the OOM killer too.
I don't think it's OOM.
We have long had the rule that order <= PAGE_ALLOC_COSTLY_ORDER (which is 3) allocations imply __GFP_RETRY unless you explicitly ask it not to.
And THREAD_SIZE_ORDER is still smaller than that.
Sure, if the system makes no progress at all, it will still oom for allocations like that, but that's *not* going to happen for something like a 32GB machine afaik.
And if it was the actual dup_task_struct() that failed (due to alloc_thread_info_node() now failing), it should have returned ENOMEM anyway.
So EAGAIN is due to something else.
The only cases for fork() returning EAGAIN I can find are the RLIMIT_NPROC and max_threads checks.
And the thing is, the default value for RLIMIT_NPROC is actually initialized based on THREAD_SIZE (which doubled), so maybe it's really just that rlimit check that now triggers.
Hmm?
Linus
| |