[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20190702130318.39d187dc27dbdd9267788165@linux-foundation.org>
Date: Tue, 2 Jul 2019 13:03:18 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Waiman Long <longman@...hat.com>
Cc: Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Alexander Viro <viro@...iv.linux.org.uk>,
Jonathan Corbet <corbet@....net>,
Luis Chamberlain <mcgrof@...nel.org>,
Kees Cook <keescook@...omium.org>,
Johannes Weiner <hannes@...xchg.org>,
Michal Hocko <mhocko@...nel.org>,
Vladimir Davydov <vdavydov.dev@...il.com>, linux-mm@...ck.org,
linux-doc@...r.kernel.org, linux-fsdevel@...r.kernel.org,
cgroups@...r.kernel.org, linux-kernel@...r.kernel.org,
Roman Gushchin <guro@...com>,
Shakeel Butt <shakeelb@...gle.com>,
Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: [PATCH] mm, slab: Extend slab/shrink to shrink all the memcg
caches
On Tue, 2 Jul 2019 14:37:30 -0400 Waiman Long <longman@...hat.com> wrote:
> Currently, a value of '1" is written to /sys/kernel/slab/<slab>/shrink
> file to shrink the slab by flushing all the per-cpu slabs and free
> slabs in partial lists. This applies only to the root caches, though.
>
> Extends this capability by shrinking all the child memcg caches and
> the root cache when a value of '2' is written to the shrink sysfs file.
Why?
Please fully describe the value of the proposed feature to or users.
Always.
>
> ...
>
> --- a/Documentation/ABI/testing/sysfs-kernel-slab
> +++ b/Documentation/ABI/testing/sysfs-kernel-slab
> @@ -429,10 +429,12 @@ KernelVersion: 2.6.22
> Contact: Pekka Enberg <penberg@...helsinki.fi>,
> Christoph Lameter <cl@...ux-foundation.org>
> Description:
> - The shrink file is written when memory should be reclaimed from
> - a cache. Empty partial slabs are freed and the partial list is
> - sorted so the slabs with the fewest available objects are used
> - first.
> + A value of '1' is written to the shrink file when memory should
> + be reclaimed from a cache. Empty partial slabs are freed and
> + the partial list is sorted so the slabs with the fewest
> + available objects are used first. When a value of '2' is
> + written, all the corresponding child memory cgroup caches
> + should be shrunk as well. All other values are invalid.
One would expect this to be a bitfield, like /proc/sys/vm/drop_caches.
So writing 3 does both forms of shrinking.
Yes, it happens to be the case that 2 is a superset of 1, but what
about if we add "4"?
Powered by blists - more mailing lists