[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220419183654.axbxcjehs6fpqg4z@moria.home.lan>
Date: Tue, 19 Apr 2022 14:36:54 -0400
From: Kent Overstreet <kent.overstreet@...il.com>
To: Roman Gushchin <roman.gushchin@...ux.dev>
Cc: linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
Dave Chinner <dchinner@...hat.com>,
linux-kernel@...r.kernel.org, Johannes Weiner <hannes@...xchg.org>,
Michal Hocko <mhocko@...nel.org>,
Shakeel Butt <shakeelb@...gle.com>,
Yang Shi <shy828301@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH rfc 0/5] mm: introduce shrinker sysfs interface
On Fri, Apr 15, 2022 at 05:27:51PM -0700, Roman Gushchin wrote:
> 7) Don't display cgroups with less than 500 attached objects
> $ echo 500 > count_memcg
> $ cat count_memcg
> 53 817
> 1868 886
> 2396 799
> 2462 861
>
> 8) Don't display cgroups with less than 500 attached objects (sum over all nodes)
> $ echo "500" > count_memcg_node
> $ cat count_memcg_node
> 53 810 7
> 1868 886 0
> 2396 799 0
> 2462 861 0
>
> 9) Scan system/root shrinker
> $ cat count
> 212
> $ echo 100 > scan
> $ cat scan
> 97
> $ cat count
> 115
This part seems entirely overengineered though and a really bad idea - can we
please _not_ store query state in the kernel? It's not thread safe, and it seems
like overengineering before we've done the basics (just getting this stuff in
sysfs is a major improvement!).
I know kmemleak does something kinda sorta like this, but that's a special
purpose debugging tool and this looks to be something more general purpose
that'll get used in production.
Powered by blists - more mailing lists