All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Stefan Bader <stefan.bader@canonical.com>
Cc: linux-kernel@vger.kernel.org,
	Eric Dumazet <eric.dumazet@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: fs/stat: Reduce memory requirements for stat_open
Date: Thu, 12 Jun 2014 15:41:49 +0200	[thread overview]
Message-ID: <20140612134149.GC4296@osiris> (raw)
In-Reply-To: <1402578017-16637-1-git-send-email-stefan.bader@canonical.com>

On Thu, Jun 12, 2014 at 03:00:17PM +0200, Stefan Bader wrote:
> When reading from /proc/stat we allocate a large buffer to maximise
> the chances of the results being from a single run and thus internally
> consistent.  This currently is sized at 128 * num_possible_cpus() which,
> in the face of kernels sized to handle large configurations (256 cpus
> plus), results in the buffer being an order-4 allocation or more.
> When system memory becomes fragmented these cannot be guarenteed, leading
> to read failures due to allocation failures.
> 
> There seem to be two issues in play here.  Firstly the allocation is
> going to be vastly over sized in the common case, as we only consume the
> buffer based on the num_online_cpus().  Secondly, regardless of size we
> should not be requiring allocations greater than PAGE_ALLOC_COSTLY_ORDER
> as allocations above this order are significantly more likely to fail.
> 
> The following patch addesses both of these issues.  Does that make sense
> generally? It seemed to stop top complaining wildly for the reporter
> at least.

Hi Stefan,

see also https://lkml.org/lkml/2014/5/21/341

and one possible solution:

https://lkml.org/lkml/2014/5/30/191

and the other one:

https://lkml.org/lkml/2014/6/12/92
https://lkml.org/lkml/2014/6/12/107

Thanks,
Heiko


  reply	other threads:[~2014-06-12 13:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-12 13:00 fs/stat: Reduce memory requirements for stat_open Stefan Bader
2014-06-12 13:41 ` Heiko Carstens [this message]
2014-06-12 14:02   ` Stefan Bader
2014-06-24 23:44     ` David Rientjes
2014-06-25  7:04       ` Stefan Bader
2014-06-25 22:52         ` David Rientjes
2014-06-25 22:54           ` Andrew Morton
2014-07-08 13:09 ` Peter Zijlstra
2014-07-08 13:30   ` Stefan Bader

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140612134149.GC4296@osiris \
    --to=heiko.carstens@de.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stefan.bader@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.