linux-kernel - Re: [PATCH v8 03/17] mm: Assign id to every memcg-aware shrinker

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180703174744.GB4834@bombadil.infradead.org>
Date:   Tue, 3 Jul 2018 10:47:44 -0700
From:   Matthew Wilcox <willy@...radead.org>
To:     Shakeel Butt <shakeelb@...gle.com>
Cc:     Kirill Tkhai <ktkhai@...tuozzo.com>,
        Vladimir Davydov <vdavydov.dev@...il.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Johannes Weiner <hannes@...xchg.org>,
        Michal Hocko <mhocko@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Philippe Ombredanne <pombredanne@...b.com>,
        stummala@...eaurora.org, gregkh@...uxfoundation.org,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Roman Gushchin <guro@...com>, mka@...omium.org,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Chris Wilson <chris@...is-wilson.co.uk>, longman@...hat.com,
        Minchan Kim <minchan@...nel.org>,
        Huang Ying <ying.huang@...el.com>,
        Mel Gorman <mgorman@...hsingularity.net>, jbacik@...com,
        Guenter Roeck <linux@...ck-us.net>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux MM <linux-mm@...ck.org>, lirongqing@...du.com,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v8 03/17] mm: Assign id to every memcg-aware shrinker

On Tue, Jul 03, 2018 at 08:46:28AM -0700, Shakeel Butt wrote:
> On Tue, Jul 3, 2018 at 8:27 AM Matthew Wilcox <willy@...radead.org> wrote:
> > This will actually reduce the size of each shrinker and be more
> > cache-efficient when calling the shrinkers.  I think we can also get
> > rid of the shrinker_rwsem eventually, but let's leave it for now.
> 
> Can you explain how you envision shrinker_rwsem can be removed? I am
> very much interested in doing that.

Sure.  Right now we have 3 uses of shrinker_rwsem -- two for adding and
removing shrinkers to the list and one for walking the list.  If we switch
to an IDR then we can use a spinlock for adding/removing shrinkers and
the RCU read lock for looking up an entry in the IDR each iteration of
the loop.

We'd need to stop the shrinker from disappearing underneath us while we
drop the RCU lock, so we'd need a refcount in the shrinker, and to free
the shrinkers using RCU.  We do similar things for other data structures,
so this is all pretty well understood.