linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: dormando <dormando@rydia.net>
Cc: Rik van Riel <riel@redhat.com>,
	Seiji Aguchi <seiji.aguchi@hds.com>,
	Satoru Moriya <satoru.moriya@hds.com>,
	Randy Dunlap <rdunlap@xenotime.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"lwoodman@redhat.com" <lwoodman@redhat.com>,
	"hughd@google.com" <hughd@google.com>
Subject: Re: [PATCH] add extra free kbytes tunable
Date: Tue, 19 Feb 2013 15:29:36 -0800	[thread overview]
Message-ID: <20130219152936.f079c971.akpm@linux-foundation.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1302171546120.10836@dflat>

On Sun, 17 Feb 2013 15:48:31 -0800 (PST)
dormando <dormando@rydia.net> wrote:

> Add a userspace visible knob to tell the VM to keep an extra amount
> of memory free, by increasing the gap between each zone's min and
> low watermarks.

The problem is that adding this tunable will constrain future VM
implementations.  We will forever need to at least retain the
pseudo-file.  We will also need to make some effort to retain its
behaviour.

It would of course be better to fix things so you don't need to tweak
VM internals to get acceptable behaviour.

You said:

: We have a server workload wherein machines with 100G+ of "free" memory
: (used by page cache), scattered but frequent random io reads from 12+
: SSD's, and 5gbps+ of internet traffic, will frequently hit direct reclaim
: in a few different ways.
: 
: 1) It'll run into small amounts of reclaim randomly (a few hundred
: thousand).
: 
: 2) A burst of reads or traffic can cause extra pressure, which kswapd
: occasionally responds to by freeing up 40g+ of the pagecache all at once
: (!) while pausing the system (Argh).
: 
: 3) A blip in an upstream provider or failover from a peer causes the
: kernel to allocate massive amounts of memory for retransmission
: queues/etc, potentially along with buffered IO reads and (some, but not
: often a ton) of new allocations from an application. This paired with 2)
: can cause the box to stall for 15+ seconds.

Can we prioritise these?  2) looks just awful - kswapd shouldn't just
go off and free 40G of pagecache.  Do you know what's actually in that
pagecache?  Large number of small files or small number of (very) large
files?

  reply	other threads:[~2013-02-19 23:29 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-12  2:01 extra free kbytes tunable dormando
2013-02-15 22:21 ` Seiji Aguchi
2013-02-15 22:25   ` Rik van Riel
2013-02-17 23:48     ` [PATCH] add " dormando
2013-02-19 23:29       ` Andrew Morton [this message]
2013-02-20  5:19         ` dormando
2013-02-22 17:56           ` Johannes Weiner
2013-02-26 10:47             ` Mel Gorman
2013-02-26 15:13               ` Johannes Weiner
2013-02-26 16:25                 ` Mel Gorman
2013-03-01  9:22             ` Simon Jeons
2013-03-01  9:31               ` Simon Jeons
2013-03-01 22:33                 ` Hugh Dickins
2013-03-02  0:10                   ` Simon Jeons
2013-03-02  1:42                     ` Hugh Dickins
2013-03-02  2:42                       ` Simon Jeons
2013-03-02  3:08                         ` Hugh Dickins
2013-03-02  4:06                           ` Simon Jeons
2013-03-09  1:08                           ` Simon Jeons
2013-02-17 23:54     ` dormando
2013-02-15 22:49   ` Satoru Moriya

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=20130219152936.f079c971.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=dormando@rydia.net \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lwoodman@redhat.com \
    --cc=rdunlap@xenotime.net \
    --cc=riel@redhat.com \
    --cc=satoru.moriya@hds.com \
    --cc=seiji.aguchi@hds.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).