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 9F248C433DB for ; Fri, 5 Feb 2021 16:49:49 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CE60564EEB for ; Fri, 5 Feb 2021 16:49:48 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE60564EEB 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 DAFBD6B0070; Fri, 5 Feb 2021 11:49:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D5EAB6B0071; Fri, 5 Feb 2021 11:49:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C29B26B0073; Fri, 5 Feb 2021 11:49:47 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0252.hostedemail.com [216.40.44.252]) by kanga.kvack.org (Postfix) with ESMTP id AAB256B0070 for ; Fri, 5 Feb 2021 11:49:47 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6B7FB1EE6 for ; Fri, 5 Feb 2021 16:49:47 +0000 (UTC) X-FDA: 77784800814.13.head84_070c251275e6 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 4BC6018140B67 for ; Fri, 5 Feb 2021 16:49:47 +0000 (UTC) X-HE-Tag: head84_070c251275e6 X-Filterd-Recvd-Size: 13038 Received: from mail-ej1-f47.google.com (mail-ej1-f47.google.com [209.85.218.47]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Fri, 5 Feb 2021 16:49:46 +0000 (UTC) Received: by mail-ej1-f47.google.com with SMTP id jj19so12966716ejc.4 for ; Fri, 05 Feb 2021 08:49:46 -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=Kq0XY+Ms6gfdK8bjLjpUnlnSk7Bhm/wJzqbGXlSuwXU=; b=SOI74/tVA2jgFjJy32JVSZsFRVk0wFZBNhEUBLq2Qn6WHOXf1+tkN6BGtUI2Uuq5QG /6mqClkrpjCEqWF8KDTufo844cHRqRgXAuSQrrCsYzVr3fj672p4+kOYHlQ/gaIP70OQ emqFsodl9XVqjdnVnai3Y9veHYmcyK7FaSJi5GZIFtkjOHN4JHFUNJHKu6hPopD63UqD LiHQsQgKx8fxILSdKGNRCpGBb6u/bDMGUqHpUS/p+5/d+YFfquWIRYzhbuqFfGqiI8IQ 0X+BRYy8ttxCOLUj9JGorFSbXNpjY8CyuX1J7QpW1VD3zfmHFe6simw+YymxyUlva4CC 9OKQ== 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=Kq0XY+Ms6gfdK8bjLjpUnlnSk7Bhm/wJzqbGXlSuwXU=; b=hIwC7XsWl+it8Bih95mihkiQL+Dt65Dxnsh/y1UD4d6NZuxf6wZYWerOAhrTvS25uL /DZA4ZMUHjuN2BznFoTtrThzlp3FsEiqVmovJV4udXbGuMGwbi64Owqhe9KdtC1ePPuk lkcp9ZmwGHDbBFX+uqMBc3b1F2/RVsUpPj04ADW8rSQzsJuoJHceIog9OFJ0iW4Drq3u e12LRm/eHAyzniTq7z9oxd3opE+KMs9yky0oRxAPVhyChRIfUrfkgbr12IzWsb/2ZdLz s3NUzLVMGu04zTt8wP6foQ6IYRpsNYIwoF3fup799jGjezSevdtk7byPJMCQZLBj+FMh KZSg== X-Gm-Message-State: AOAM53297XCF3ebMYkHeK846h1oM3wdOPQ6ycVJ0NwOooiFKMXqyhxts hlhDz93Bj7yj77izwePs9U+fZJzCG36/BzZrNEA= X-Google-Smtp-Source: ABdhPJwaldRccZNXsjcyzV8hSAn8V23I+60L9ilnYbzqF7ou7WrR6F0nSS7IW1hkP+SOr5Fw31f1LTYy1sqMmoRvpUA= X-Received: by 2002:a17:906:eddd:: with SMTP id sb29mr4705160ejb.383.1612543785528; Fri, 05 Feb 2021 08:49:45 -0800 (PST) MIME-Version: 1.0 References: <20210203172042.800474-1-shy828301@gmail.com> <20210203172042.800474-8-shy828301@gmail.com> <374a5513-9e80-f240-ef82-ef35c13931c1@virtuozzo.com> <9d6862c2-15a6-93ab-057d-512cb2a6af2b@virtuozzo.com> In-Reply-To: <9d6862c2-15a6-93ab-057d-512cb2a6af2b@virtuozzo.com> From: Yang Shi Date: Fri, 5 Feb 2021 08:49:33 -0800 Message-ID: Subject: Re: [v6 PATCH 07/11] mm: vmscan: add per memcg shrinker nr_deferred To: Kirill Tkhai Cc: Roman Gushchin , Vlastimil Babka , 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 Fri, Feb 5, 2021 at 6:38 AM Kirill Tkhai wrote: > > On 04.02.2021 20:17, Yang Shi wrote: > > On Thu, Feb 4, 2021 at 12:31 AM Kirill Tkhai wrote: > >> > >> On 03.02.2021 20:20, 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 | 7 +++--- > >>> mm/vmscan.c | 45 ++++++++++++++++++++++++-------------- > >>> 2 files changed, 33 insertions(+), 19 deletions(-) > >>> > >>> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > >>> index 4c9253896e25..c457fc7bc631 100644 > >>> --- a/include/linux/memcontrol.h > >>> +++ b/include/linux/memcontrol.h > >>> @@ -93,12 +93,13 @@ struct lruvec_stat { > >>> }; > >>> > >>> /* > >>> - * Bitmap of shrinker::id corresponding to memcg-aware shrinkers, > >>> - * which have elements charged to this memcg. > >>> + * Bitmap and deferred work of shrinker::id corresponding to memcg-aware > >>> + * shrinkers, which have elements charged to this memcg. > >>> */ > >>> struct shrinker_info { > >>> struct rcu_head rcu; > >>> - unsigned long map[]; > >>> + atomic_long_t *nr_deferred; > >>> + unsigned long *map; > >>> }; > >>> > >>> /* > >>> diff --git a/mm/vmscan.c b/mm/vmscan.c > >>> index dc0d69e081b0..d9126f12890f 100644 > >>> --- a/mm/vmscan.c > >>> +++ b/mm/vmscan.c > >>> @@ -196,10 +196,12 @@ static void free_shrinker_info_rcu(struct rcu_head *head) > >>> } > >>> > >>> static int expand_one_shrinker_info(struct mem_cgroup *memcg, > >>> - int size, int old_size) > >>> + int m_size, int d_size, > >>> + int old_m_size, int old_d_size) > >>> { > >>> struct shrinker_info *new, *old; > >>> int nid; > >>> + int size = m_size + d_size; > >>> > >>> for_each_node(nid) { > >>> old = rcu_dereference_protected( > >>> @@ -212,9 +214,15 @@ static int expand_one_shrinker_info(struct mem_cgroup *memcg, > >>> if (!new) > >>> return -ENOMEM; > >>> > >>> - /* Set all old bits, clear all new bits */ > >>> - memset(new->map, (int)0xff, old_size); > >>> - memset((void *)new->map + old_size, 0, size - old_size); > >>> + new->nr_deferred = (atomic_long_t *)(new + 1); > >>> + new->map = (void *)new->nr_deferred + d_size; > >>> + > >>> + /* map: set all old bits, clear all new bits */ > >>> + memset(new->map, (int)0xff, old_m_size); > >>> + memset((void *)new->map + old_m_size, 0, m_size - old_m_size); > >>> + /* nr_deferred: copy old values, clear all new values */ > >>> + memcpy(new->nr_deferred, old->nr_deferred, old_d_size); > >>> + memset((void *)new->nr_deferred + old_d_size, 0, d_size - old_d_size); > >>> > >>> rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_info, new); > >>> call_rcu(&old->rcu, free_shrinker_info_rcu); > >>> @@ -229,9 +237,6 @@ void free_shrinker_info(struct mem_cgroup *memcg) > >>> struct shrinker_info *info; > >>> int nid; > >>> > >>> - if (mem_cgroup_is_root(memcg)) > >>> - return; > >>> - > >>> for_each_node(nid) { > >>> pn = mem_cgroup_nodeinfo(memcg, nid); > >>> info = rcu_dereference_protected(pn->shrinker_info, true); > >>> @@ -244,12 +249,13 @@ int alloc_shrinker_info(struct mem_cgroup *memcg) > >>> { > >>> struct shrinker_info *info; > >>> int nid, size, ret = 0; > >>> - > >>> - if (mem_cgroup_is_root(memcg)) > >>> - return 0; > >>> + int m_size, d_size = 0; > >>> > >>> down_write(&shrinker_rwsem); > >>> - size = NR_MAX_TO_SHR_MAP_SIZE(shrinker_nr_max); > >>> + m_size = NR_MAX_TO_SHR_MAP_SIZE(shrinker_nr_max); > >>> + d_size = shrinker_nr_max * sizeof(atomic_long_t); > >>> + size = m_size + d_size; > >>> + > >>> for_each_node(nid) { > >>> info = kvzalloc_node(sizeof(*info) + size, GFP_KERNEL, nid); > >>> if (!info) { > >>> @@ -257,6 +263,8 @@ int alloc_shrinker_info(struct mem_cgroup *memcg) > >>> ret = -ENOMEM; > >>> break; > >>> } > >>> + info->nr_deferred = (atomic_long_t *)(info + 1); > >>> + info->map = (void *)info->nr_deferred + d_size; > >>> rcu_assign_pointer(memcg->nodeinfo[nid]->shrinker_info, info); > >>> } > >>> up_write(&shrinker_rwsem); > >>> @@ -268,10 +276,16 @@ static int expand_shrinker_info(int new_id) > >>> { > >>> int size, old_size, ret = 0; > >>> int new_nr_max = new_id + 1; > >>> + int m_size, d_size = 0; > >>> + int old_m_size, old_d_size = 0; > >>> struct mem_cgroup *memcg; > >>> > >>> - size = NR_MAX_TO_SHR_MAP_SIZE(new_nr_max); > >>> - old_size = NR_MAX_TO_SHR_MAP_SIZE(shrinker_nr_max); > >>> + m_size = NR_MAX_TO_SHR_MAP_SIZE(new_nr_max); > >>> + d_size = new_nr_max * sizeof(atomic_long_t); > >>> + size = m_size + d_size; > >>> + old_m_size = NR_MAX_TO_SHR_MAP_SIZE(shrinker_nr_max); > >>> + old_d_size = shrinker_nr_max * sizeof(atomic_long_t); > >>> + old_size = old_m_size + old_d_size; > >>> if (size <= old_size) > >>> goto out; > >> > >> Before this patch we used to allocate shrinker_info with BITS_PER_LONG batching. > >> So, first registered shrinker used to allocate a map of unsigned long size, and > >> we could to allocate 63 more shrinkers without maps expanding. > >> > >> After this patch we will expand maps on every shrinker registration, won't we? > > > > Yes, I'm supposed "maps" means "info".I'm supposed the most shrinkers > > should be registered at boot time, and typically very few memcgs are > > created at boot time so I didn't treat it as a hot path. > > Not so. Every mount adds at least one shrinker, so they can actively be added > during normal system work. > > E.g., on our production system (containers) several thousand shrinkers > is not a rare situation. Aha, yes, I missed this point. > > >> What do you think about batching here? > > > > Just off the top of my head, we could allocate, for example, 64 > > nr_deferred (64 * sizeof(atomic_long_t)) so that we just need to > > expand info for every 64 shrinker registrations. Maybe define it > > depends on the machine (64 bit - 64, 32 bit - 32). > > > > Why 64? Basically a magic number. And when I was investigating that > > list_lru reparent race issue > > (https://lore.kernel.org/linux-mm/20201202171749.264354-1-shy828301@gmail.com/) > > I happened to notice that there are at most 64 shrinkers registered in > > our production environment (a typical data center configuration). > > > > How do you think about it? > > I think 64 is OK for now. We may use some #define to set this value, so we will > be able to change it easily in the future. BITS_PER_LONG might be better. We could reuse all the existing logic without adding too much new code. > > >>> > >>> @@ -280,9 +294,8 @@ static int expand_shrinker_info(int new_id) > >>> > >>> memcg = mem_cgroup_iter(NULL, NULL, NULL); > >>> do { > >>> - if (mem_cgroup_is_root(memcg)) > >>> - continue; > >>> - ret = expand_one_shrinker_info(memcg, size, old_size); > >>> + ret = expand_one_shrinker_info(memcg, m_size, d_size, > >>> + old_m_size, old_d_size); > >>> if (ret) { > >>> mem_cgroup_iter_break(NULL, memcg); > >>> goto out; > >>> > >> > >> >