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=-13.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 ACAA8C47087 for ; Wed, 26 May 2021 03:02:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2A358613F5 for ; Wed, 26 May 2021 03:02:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2A358613F5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A8AAA6B007D; Tue, 25 May 2021 23:02:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A3ACD6B007E; Tue, 25 May 2021 23:02:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8DBD86B0080; Tue, 25 May 2021 23:02:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0206.hostedemail.com [216.40.44.206]) by kanga.kvack.org (Postfix) with ESMTP id 5AB266B007D for ; Tue, 25 May 2021 23:02:16 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E2B57181AEF39 for ; Wed, 26 May 2021 03:02:15 +0000 (UTC) X-FDA: 78181883430.20.93FB720 Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by imf02.hostedemail.com (Postfix) with ESMTP id 3F65740002F1 for ; Wed, 26 May 2021 03:02:11 +0000 (UTC) Received: by mail-pg1-f177.google.com with SMTP id 6so24356179pgk.5 for ; Tue, 25 May 2021 20:02:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ispGwrZyOkLcLokLfDTklwnT3S2zfpijrNq/+3Yb1oo=; b=K6y9IFTgpzx75/3GUC8pYV2qy6+0Cfs7Wd+um/VLcfOo6GG17W/nUJ03vwJNMHo+4x qxNFb6F7Yvki98yE2edv/l3D9ZqOXH12a51RKsu79Kqn2rU0cGng/IXkH/qu+HBQjWGz tlXupAzvikjEtYhRAqifcrQFVSDH+1+e3WNEc6aN5QdiQViQcionTdWsX1TrRDlqsoBR /6uRFGyb1NWFCZGiGGRNK5MifqkBAuK9ufG+i2vFaXa0GJ7V6HU3SaEY9XQW/OvuoMWc U7+L12kYp5OfU84suvjOYmWEd8PtPqvDkeVa4KsyRNHKO8l/hsZAwS8EK4Us6YBtmhji Pn1g== 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=ispGwrZyOkLcLokLfDTklwnT3S2zfpijrNq/+3Yb1oo=; b=BBchdAgPz4WhXfpA29nZ9SVYxOeGOUFglujwTkaAMWrhWZv+p9X2PEPKfCWpKMn11s 1/01kbHl7hwmS+2EoHiZ/1VjwBJbsw7M3Jas7uIBc1gdaDV0OtSthsPojHwpWUKY92Tq wFf90elu/4tE6R5l2htgZ92nkhbcqzgtWg+2o9T98b/7qdh7g+eeTSRmCxSMpBfV2tcd 6IgEYaChyzk8QQBDOosP5vtbstr+y4oK/MUlp6f6m1vUKUFXF4KueiG8VFC6WA6gdLnd 9NpYWZTt2xyNA9O7AJ1oamF2+KZrn9fBcMV/O9eGFK5vlnsozJsZoEMXvAwGG+5SDnQe ntwA== X-Gm-Message-State: AOAM530a9KPov0FFAJEwW791QbZ2B1Zzncy6GAUnfHPvUXHkJlbJ2+vU z1AEiQnFsLBPxYLcGrGp1nLK3aPgAsCWN5J+rWpSk3IWqIprBbLr X-Google-Smtp-Source: ABdhPJyT8PbK6O+mhRnB55VUYtuwkVtOQ4pIYd8a3oHC9BRBYwEjM2hH7IF784rGLEfQZWSUKm9iRc2CPz1xOfFKWb8= X-Received: by 2002:a05:6a00:2493:b029:2c4:b6dd:d389 with SMTP id c19-20020a056a002493b02902c4b6ddd389mr33537895pfv.2.1621998133816; Tue, 25 May 2021 20:02:13 -0700 (PDT) MIME-Version: 1.0 References: <20210421070059.69361-1-songmuchun@bytedance.com> <20210421070059.69361-9-songmuchun@bytedance.com> In-Reply-To: From: Muchun Song Date: Wed, 26 May 2021 11:01:37 +0800 Message-ID: Subject: Re: [External] Re: [RFC PATCH v3 08/12] mm: memcontrol: introduce memcg_reparent_ops To: Roman Gushchin Cc: Johannes Weiner , Michal Hocko , Andrew Morton , Shakeel Butt , Vladimir Davydov , LKML , Linux Memory Management List , Xiongchun duan , fam.zheng@bytedance.com, "Singh, Balbir" , Yang Shi , Alex Shi Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=bytedance-com.20150623.gappssmtp.com header.s=20150623 header.b=K6y9IFTg; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf02.hostedemail.com: domain of songmuchun@bytedance.com designates 209.85.215.177 as permitted sender) smtp.mailfrom=songmuchun@bytedance.com X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3F65740002F1 X-Stat-Signature: 9na8e1otj1k1i9rirpmkxfe56ecofw5g X-HE-Tag: 1621998131-660599 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, May 26, 2021 at 1:46 AM Roman Gushchin wrote: > > On Wed, Apr 21, 2021 at 03:00:55PM +0800, Muchun Song wrote: > > In the previous patch, we know how to make the lruvec lock safe when the > > LRU pages reparented. We should do something like following. > > > > memcg_reparent_objcgs(memcg) > > 1) lock > > // lruvec belongs to memcg and lruvec_parent belongs to parent memcg. > > spin_lock(&lruvec->lru_lock); > > spin_lock(&lruvec_parent->lru_lock); > > > > 2) do reparent > > // Move all the pages from the lruvec list to the parent lruvec list. > > > > 3) unlock > > spin_unlock(&lruvec_parent->lru_lock); > > spin_unlock(&lruvec->lru_lock); > > > > Apart from the page lruvec lock, the deferred split queue lock (THP only) > > also needs to do something similar. So we extracted the necessary 3 steps > > in the memcg_reparent_objcgs(). > > > > memcg_reparent_objcgs(memcg) > > 1) lock > > memcg_reparent_ops->lock(memcg, parent); > > > > 2) reparent > > memcg_reparent_ops->reparent(memcg, reparent); > > > > 3) unlock > > memcg_reparent_ops->unlock(memcg, reparent); > > > > Now there are two different locks (e.g. lruvec lock and deferred split > > queue lock) need to use this infrastructure. In the next patch, we will > > use those APIs to make those locks safe when the LRU pages reparented. > > > > Signed-off-by: Muchun Song > > --- > > include/linux/memcontrol.h | 11 +++++++++++ > > mm/memcontrol.c | 49 ++++++++++++++++++++++++++++++++++++++++++++-- > > 2 files changed, 58 insertions(+), 2 deletions(-) > > > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > > index 228263f2c82b..b12847b0be09 100644 > > --- a/include/linux/memcontrol.h > > +++ b/include/linux/memcontrol.h > > @@ -355,6 +355,17 @@ struct mem_cgroup { > > /* WARNING: nodeinfo must be the last member here */ > > }; > > > > +struct memcg_reparent_ops { > > + struct list_head list; > > + > > + /* Irq is disabled before calling those functions. */ > > + void (*lock)(struct mem_cgroup *memcg, struct mem_cgroup *parent); > > + void (*unlock)(struct mem_cgroup *memcg, struct mem_cgroup *parent); > > + void (*reparent)(struct mem_cgroup *memcg, struct mem_cgroup *parent); > > +}; > > + > > +void __init register_memcg_repatent(struct memcg_reparent_ops *ops); > > + > > /* > > * size of first charge trial. "32" comes from vmscan.c's magic value. > > * TODO: maybe necessary to use big numbers in big irons. > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index a48403e5999c..f88fe2f06f5b 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -330,6 +330,41 @@ static struct obj_cgroup *obj_cgroup_alloc(void) > > return objcg; > > } > > > > +static LIST_HEAD(reparent_ops_head); > > Because this list is completely static, why not make a build-time initialized > array instead? I didn't think of using an array before. The first idea that popped out was a list. But you remind me of the array. I'd love to replace it with the array. Thanks, Roman. > I guess it's a more canonical way of solving problems like this. > The proposed API looks good to me.