lkml.org 
[lkml]   [2019]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] mm, slab: Extend slab/shrink to shrink all the memcg caches
    From
    Date
    On 7/3/19 10:37 AM, Michal Hocko wrote:
    > On Wed 03-07-19 09:12:13, Waiman Long wrote:
    >> On 7/3/19 2:56 AM, Michal Hocko wrote:
    >>> On Tue 02-07-19 14:37:30, Waiman Long 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 do we need a new value for this functionality? I would tend to think
    >>> that skipping memcg caches is a bug/incomplete implementation. Or is it
    >>> a deliberate decision to cover root caches only?
    >> It is just that I don't want to change the existing behavior of the
    >> current code. It will definitely take longer to shrink both the root
    >> cache and the memcg caches.
    > Does that matter? To whom and why? I do not expect this interface to be
    > used heavily.
    The only concern that I can see is the fact that I need to take the
    slab_mutex when iterating the memcg list to prevent concurrent
    modification. That may have some impact on other applications running in
    the system. However, I can put a precaution statement on the user-doc to
    discuss the potential performance impact.
    >> If we all agree that the only sensible
    >> operation is to shrink root cache and the memcg caches together. I am
    >> fine just adding memcg shrink without changing the sysfs interface
    >> definition and be done with it.
    > The existing documentation is really modest on the actual semantic:
    > 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.
    >
    > which to me sounds like all slabs are free and nobody should be really
    > thinking of memcgs. This is simply drop_caches kinda thing. We surely do
    > not want to drop caches only for the root memcg for /proc/sys/vm/drop_caches
    > right?
    >
    I am planning to reword the document to make the effect of using this
    sysfs file more explicit.

    Cheers,
    Longman

    \
     
     \ /
      Last update: 2019-07-03 17:15    [W:3.986 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site