All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@fb.com>
To: Johannes Weiner <hannes@cmpxchg.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Rik van Riel <riel@redhat.com>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH 4/4] mm: zero-seek shrinkers
Date: Wed, 10 Oct 2018 01:03:50 +0000	[thread overview]
Message-ID: <e01c4f441e24bb31816a3080389dcae7b49cc1ff.camel@fb.com> (raw)
In-Reply-To: <20181009184732.762-5-hannes@cmpxchg.org>

On Tue, 2018-10-09 at 14:47 -0400, Johannes Weiner wrote:

> These workloads also deal with tens of thousands of open files and
> use
> /proc for introspection, which ends up growing the proc_inode_cache
> to
> absurdly large sizes - again at the cost of valuable cache space,
> which isn't a reasonable trade-off, given that proc inodes can be
> re-created without involving the disk.
> 
> This patch implements a "zero-seek" setting for shrinkers that
> results
> in a target ratio of 0:1 between their objects and IO-backed
> caches. This allows such virtual caches to grow when memory is
> available (they do cache/avoid CPU work after all), but effectively
> disables them as soon as IO-backed objects are under pressure.
> 
> It then switches the shrinkers for procfs and sysfs metadata, as well
> as excess page cache shadow nodes, to the new zero-seek setting.

This patch looks like a great step in the right
direction, though I do not know whether it is
aggressive enough.

Given that internal slab fragmentation will
prevent the slab cache from returning a slab to
the VM if just one object in that slab is still
in use, there may well be workloads where we
should just put a hard cap on the number of
freeable items these slabs, and reclaim them
preemptively.

However, I do not know for sure, and this patch
seems like a big improvement over what we had
before, so ...

> Reported-by: Domas Mituzas <dmituzas@fb.com>
> Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>

Reviewed-by: Rik van Riel <riel@surriel.com>


  parent reply	other threads:[~2018-10-10  1:04 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-09 18:47 [PATCH 0/4] mm: workingset & shrinker fixes Johannes Weiner
2018-10-09 18:47 ` [PATCH 1/4] mm: workingset: don't drop refault information prematurely fix Johannes Weiner
2018-10-10  0:55   ` Rik van Riel
2018-10-09 18:47 ` [PATCH 2/4] mm: workingset: use cheaper __inc_lruvec_state in irqsafe node reclaim Johannes Weiner
2018-10-10  0:55   ` Rik van Riel
2018-10-09 18:47 ` [PATCH 3/4] mm: workingset: add vmstat counter for shadow nodes Johannes Weiner
2018-10-09 22:04   ` Andrew Morton
2018-10-10 14:02     ` Johannes Weiner
2018-10-09 22:08   ` Andrew Morton
2018-10-10 15:05     ` Johannes Weiner
2018-10-16  8:49     ` Mel Gorman
2018-10-16 22:27       ` Andrew Morton
2018-10-09 18:47 ` [PATCH 4/4] mm: zero-seek shrinkers Johannes Weiner
2018-10-09 22:15   ` Andrew Morton
2018-10-09 22:17     ` Andrew Morton
2018-10-10  1:03   ` Rik van Riel [this message]
2018-10-10 15:15     ` Johannes Weiner
2018-10-12 13:48   ` Vlastimil Babka

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=e01c4f441e24bb31816a3080389dcae7b49cc1ff.camel@fb.com \
    --to=riel@fb.com \
    --cc=Kernel-team@fb.com \
    --cc=akpm@linux-foundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@redhat.com \
    --subject='Re: [PATCH 4/4] mm: zero-seek shrinkers' \
    /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

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.