From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 860EFC63777 for ; Thu, 3 Dec 2020 04:55:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AD0EF22203 for ; Thu, 3 Dec 2020 04:55:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AD0EF22203 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8140F6B005C; Wed, 2 Dec 2020 23:55:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C4D16B005D; Wed, 2 Dec 2020 23:55:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B3CD6B0068; Wed, 2 Dec 2020 23:55:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0008.hostedemail.com [216.40.44.8]) by kanga.kvack.org (Postfix) with ESMTP id 52A706B005C for ; Wed, 2 Dec 2020 23:55:04 -0500 (EST) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 15F92824999B for ; Thu, 3 Dec 2020 04:55:04 +0000 (UTC) X-FDA: 77550756528.20.cast23_5006bec273b9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id E8636180C07AF for ; Thu, 3 Dec 2020 04:55:03 +0000 (UTC) X-HE-Tag: cast23_5006bec273b9 X-Filterd-Recvd-Size: 6243 Received: from mail-ej1-f66.google.com (mail-ej1-f66.google.com [209.85.218.66]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Thu, 3 Dec 2020 04:55:03 +0000 (UTC) Received: by mail-ej1-f66.google.com with SMTP id a16so1522875ejj.5 for ; Wed, 02 Dec 2020 20:55:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hMZ/CoXr7rG2rPWo+uH3O4w1xYXh8+l7UsyrUayDNgc=; b=MyeceJ/MnvUoQZlEkdJUF/PNAjmS9cb+O9H0M999APAmXuB1ykgu2WYO3kNjeT/dIT x73rT0rD+oso8pvKkN7c4Rtib3zJRnnlsdI7rSXMbDmb1uQSxTmWYeMDfLJBZn9L5pV7 J7r+Q91L27e5jyXZuQj1zYzzH9TEZiA66oh1YZBO6xzEffHNXuehk7IkeKmyUe3T35ja YEPkgIE4/a1kgS63sbTyApSrfGB1xGVcmxfJTcB0B8xjO0Hc8M5BUafrFENbPOPn/mDz Uh0uOjH38vyf50ycfrws9lwYwFLHFbFVpBr0BqU9EbQMdiQbXTdf7lV6uYqNH83tYwa4 xfiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hMZ/CoXr7rG2rPWo+uH3O4w1xYXh8+l7UsyrUayDNgc=; b=OFpUaRVMgBhtp/rxG1czkW6Ye3A6Bymfs1YJk91ZPTncCB4sM5foBNdKY/71tGd8vE g0ozDjebLU4Sdepnw64uW1wAqg+Jdl0CaytL0MgImK/Ag4xHw42RiXD0Fh6Stn62RJcb GIoKfRFD0o9to/TEsqVJfnpPyZj6DZ3Ahr2KyMv8YB8Y61ato25OWPy4wFAAVjH2ByN5 gvwlLjUEtFyV1QiCkudaoME38eb+yd1QecgtRJpUJ1Jn0fGCT+Rwa9F7dnYo2F2cR+Gr q6lKm2IHS5ozEYUUZOb5gFRGdgmCfZq5r4kRToAwgQKePDsxeRgAbO90UEO8p9j0/rKF N9rw== X-Gm-Message-State: AOAM531glODYFsKi3U2zc6zAQFj8k29x2zdAR5nq0d22wQxpZF3rtJqU WoRgdi9N/AbXbk5beagZohqwtk5sIoDrlNEDB58= X-Google-Smtp-Source: ABdhPJxjSVe1Wfr/oFwfvDkweZqNU2z+vvr9rMkC/SrFrwv5wL7TTPsdwmC61tKYQZqtrZ6bKzlDVbBEy7bU8eyVdNg= X-Received: by 2002:a17:906:cd06:: with SMTP id oz6mr989147ejb.25.1606971302241; Wed, 02 Dec 2020 20:55:02 -0800 (PST) MIME-Version: 1.0 References: <20201202182725.265020-1-shy828301@gmail.com> <20201202182725.265020-6-shy828301@gmail.com> <20201203030632.GG1375014@carbon.DHCP.thefacebook.com> In-Reply-To: <20201203030632.GG1375014@carbon.DHCP.thefacebook.com> From: Yang Shi Date: Wed, 2 Dec 2020 20:54:50 -0800 Message-ID: Subject: Re: [PATCH 5/9] mm: memcontrol: add per memcg shrinker nr_deferred To: Roman Gushchin Cc: Kirill Tkhai , Shakeel Butt , Dave Chinner , Johannes Weiner , Michal Hocko , Andrew Morton , Linux MM , Linux FS-devel Mailing List , Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Dec 2, 2020 at 7:06 PM Roman Gushchin wrote: > > On Wed, Dec 02, 2020 at 10:27:21AM -0800, Yang Shi wrote: > > Currently the number of deferred objects are per shrinker, but some slabs, for example, > > vfs inode/dentry cache are per memcg, this would result in poor isolation among memcgs. > > > > The deferred objects typically are generated by __GFP_NOFS allocations, one memcg with > > excessive __GFP_NOFS allocations may blow up deferred objects, then other innocent memcgs > > may suffer from over shrink, excessive reclaim latency, etc. > > > > For example, two workloads run in memcgA and memcgB respectively, workload in B is vfs > > heavy workload. Workload in A generates excessive deferred objects, then B's vfs cache > > might be hit heavily (drop half of caches) by B's limit reclaim or global reclaim. > > > > We observed this hit in our production environment which was running vfs heavy workload > > shown as the below tracing log: > > > > <...>-409454 [016] .... 28286961.747146: mm_shrink_slab_start: super_cache_scan+0x0/0x1a0 ffff9a83046f3458: > > nid: 1 objects to shrink 3641681686040 gfp_flags GFP_HIGHUSER_MOVABLE|__GFP_ZERO pgs_scanned 1 lru_pgs 15721 > > cache items 246404277 delta 31345 total_scan 123202138 > > <...>-409454 [022] .... 28287105.928018: mm_shrink_slab_end: super_cache_scan+0x0/0x1a0 ffff9a83046f3458: > > nid: 1 unused scan count 3641681686040 new scan count 3641798379189 total_scan 602 > > last shrinker return val 123186855 > > > > The vfs cache and page cache ration was 10:1 on this machine, and half of caches were dropped. > > This also resulted in significant amount of page caches were dropped due to inodes eviction. > > > > Make nr_deferred per memcg for memcg aware shrinkers would solve the unfairness and bring > > better isolation. > > > > When memcg is not enabled (!CONFIG_MEMCG or memcg disabled), the shrinker's nr_deferred > > would be used. And non memcg aware shrinkers use shrinker's nr_deferred all the time. > > > > Signed-off-by: Yang Shi > > --- > > include/linux/memcontrol.h | 9 +++ > > mm/memcontrol.c | 112 ++++++++++++++++++++++++++++++++++++- > > mm/vmscan.c | 4 ++ > > 3 files changed, 123 insertions(+), 2 deletions(-) > > > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > > index 922a7f600465..1b343b268359 100644 > > --- a/include/linux/memcontrol.h > > +++ b/include/linux/memcontrol.h > > @@ -92,6 +92,13 @@ struct lruvec_stat { > > long count[NR_VM_NODE_STAT_ITEMS]; > > }; > > > > + > > +/* Shrinker::id indexed nr_deferred of memcg-aware shrinkers. */ > > +struct memcg_shrinker_deferred { > > + struct rcu_head rcu; > > + atomic_long_t nr_deferred[]; > > +}; > > The idea makes total sense to me. But I wonder if we can add nr_deferred to > struct list_lru_one, instead of adding another per-memcg per-shrinker entity? > I guess it can simplify the code quite a lot. What do you think? Aha, actually this exactly was what I did at the first place. But Dave NAK'ed this approach. You can find the discussion at: https://lore.kernel.org/linux-mm/20200930073152.GH12096@dread.disaster.area/.