lkml.org 
[lkml]   [2014]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] fs, seq_file: fallback to vmalloc instead of oom kill processes
On Wed, 26 Nov 2014 14:40:06 -0800 (PST) David Rientjes <rientjes@google.com> wrote:

> On Wed, 26 Nov 2014, Andrew Morton wrote:
>
> > You forgot something.
> >
> > --- a/fs/seq_file.c~fs-seq_file-fallback-to-vmalloc-instead-of-oom-kill-processes-fix
> > +++ a/fs/seq_file.c
> > @@ -36,6 +36,10 @@ static void *seq_buf_alloc(unsigned long
> > {
> > void *buf;
> >
> > + /*
> > + * __GFP_NORETRY to avoid oom-killings with high-order allocations -
> > + * it's better to fall back to vmalloc() than to kill things.
> > + */
> > buf = kmalloc(size, GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN);
> > if (!buf && size > PAGE_SIZE)
> > buf = vmalloc(size);
> >
>
> ...
>
> The slowpath tries to allocate, calls memory compaction if necessary,
> tries to allocate, calls direct reclaim, tries to allocate, call the oom
> killer and tries to allocate if we are going to loop, and then loop if
> allowed. There's no need to try to allocate if we don't call the oom
> killer since it won't succeed and there's no need to call the oom killer
> to free memory if we aren't going to retry.

My concern is that an open-coded __GFP_NORETRY is very obscure. Even
something like

#define __GFP_NO_OOM_KILL __GFP_NORETRY

would help make things a bit self-documenting.

> Even if __GFP_NO_OOM_KILL existed, it wouldn't be applicable to this
> patch: the change here is that seqfile will now return -ENOMEM instead of
> oom killing processes;

Not really? The change makes seq_buf_alloc() fall back to vmalloc()
rather than killing things. Doesn't it?

Unless the allocation is < PAGE_SIZE, in which case we do go ENOMEM.
That's daft - it would be better to vmalloc() a whole page in this
case. Not that the vmalloc is likely to be successful anyway..

> the slab allocation will no longer loop forever
> trying to allocate memory.


\
 
 \ /
  Last update: 2014-11-27 00:21    [W:0.028 / U:1.188 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site