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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 645ADE8FDC1 for ; Tue, 3 Oct 2023 23:31:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B892B8D009E; Tue, 3 Oct 2023 19:31:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B38EA8D0003; Tue, 3 Oct 2023 19:31:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D9818D009E; Tue, 3 Oct 2023 19:31:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 8B49B8D0003 for ; Tue, 3 Oct 2023 19:31:38 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 50504404C8 for ; Tue, 3 Oct 2023 23:31:38 +0000 (UTC) X-FDA: 81305749476.15.6142EC3 Received: from mail-io1-f46.google.com (mail-io1-f46.google.com [209.85.166.46]) by imf18.hostedemail.com (Postfix) with ESMTP id 79F5F1C000C for ; Tue, 3 Oct 2023 23:31:36 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gBD2iJLl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.46 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696375896; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=YWh9xWbE/lRob82wHM79Ybcqr8dXbfEsVfLAHVc30CE=; b=O8LWYsLIOuoFkiFJmkHH1AJEwn9ikPb+EqV4Ql/othw79j4/ihU2NqZeD5BcvQLsAs7reh UU+IFs6dprVpxKyUgVUGF/PKGRVEY1o3HkyDn3bEgO7Us3R+16RwmiQUTSxUQRLXOko1s8 jmeR2zf1LpicnqoSFDtMszg1gOts8Ec= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=gBD2iJLl; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf18.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.46 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696375896; a=rsa-sha256; cv=none; b=Wycubsqh6UBRjX5RIXXSUauivS/UkvaK0etQsBBECxOxVtazC3v97ithuuF8d/OX4et9Ww 989Eh4aDuoHaPvA3g0p6IEyVBfdr2DyYXvs6I/prpEhfU0eHMPCW4C6FjA61RFEXS7KS9D U+ZOY1o1PyqMprPeIkmkZwQiGHGZlWk= Received: by mail-io1-f46.google.com with SMTP id ca18e2360f4ac-79fe87cd74eso58987839f.3 for ; Tue, 03 Oct 2023 16:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696375895; x=1696980695; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=YWh9xWbE/lRob82wHM79Ybcqr8dXbfEsVfLAHVc30CE=; b=gBD2iJLl7UlDKXz+Nj7EX72dH4VM9xCIT0WhpWyEfdzBp+GvFQYNEONjklto3+xP7u 8FOX0tOIceqj1Uop61jPgkD+x9zuAcOChPOGrnTwwdYxrETiZRA3MPA7LE/FS0AgxMS6 C5UX1vjj+kOKd4XPB4Iq4NmxoyWRDkYIFgF6vlYUDJfNhU0ntJl5LkFpwXQ09wslCv/l I2MnKeUzgWItpBSkHWmz8dvnFpRff3RJe/2kgr4QZ/o4nUyzD6P9rT3+8RK47zDOYIz5 kfVCymGFlKS5jByFSiUHkLzxXC+1snop5MDofIwEkqBP+SGxkNJeaeXUddI/Y9Zf8Kac uz/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696375895; x=1696980695; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=YWh9xWbE/lRob82wHM79Ybcqr8dXbfEsVfLAHVc30CE=; b=D5289b74Zl3JHypqJ6v4rTv4s28Rj4Y5IXKOJWx2coSCGEhe+7SVof5uSwlcbv9YVa 524eYc1NImrxyCZhW/lAMK97JhOj8zd0fAO6gr88fk1nV9InS3E0PU5ecLaCj2uRKRPb XzfDerIN3DqGEWRrUy5mBKX4KiHFkY/riUp46VKDX79ICG/jI1w3v76WH/rbZUISzCqY PrBeuzSXsYJkQTBMf9OH2CeQA99xF9jO9poeRKJdjIE+DE+T4NX0vyfM0bd6FAlu10Kd spU1YXyfQClPbwA6ilcSQ1c7PZ54jR93W+KbwWHnvxhBVAcnNtMbNyJl6cgJo8RxNMwA O3MA== X-Gm-Message-State: AOJu0YxjjlWCnrkrQvVo+BHKf6kk4+fBGF587JTCiYOsZRT9dbn0VnzM OgoOR7ZIed9ycOTEeQkEW4cvWgmigumeU9CfFOw= X-Google-Smtp-Source: AGHT+IFBGdqs6v9jN2wQL6XcaflsZAowTlFvr3Qp5MrlYRDmQyM6SsxPPAhp7QS19ckhL11v3GmrPm9wccCKgn1EvN8= X-Received: by 2002:a5d:9910:0:b0:780:c787:637b with SMTP id x16-20020a5d9910000000b00780c787637bmr934771iol.0.1696375895646; Tue, 03 Oct 2023 16:31:35 -0700 (PDT) MIME-Version: 1.0 References: <20231003171329.GB314430@monkey> <20231003231422.4046187-1-nphamcs@gmail.com> In-Reply-To: From: Nhat Pham Date: Tue, 3 Oct 2023 16:31:22 -0700 Message-ID: Subject: Re: [PATCH] memcontrol: only transfer the memcg data for migration To: Yosry Ahmed Cc: akpm@linux-foundation.org, riel@surriel.com, hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeelb@google.com, muchun.song@linux.dev, tj@kernel.org, lizefan.x@bytedance.com, shuah@kernel.org, mike.kravetz@oracle.com, fvdl@google.com, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 79F5F1C000C X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 17m6b6rbraoak1ai58aosqm1zmac4srq X-HE-Tag: 1696375896-871706 X-HE-Meta: U2FsdGVkX1+NzxM/RnVdKY5z/lO6nSFhzuFRB8jtDDSViuwvMZLD/gPZBwjZMp68yumkOcBNXbw1rgyrjclMgdG6ZGF1eHimocTkEeV4RnmswUqJaAh3iCTliaAxORRlx24IfKCsUbfzaYZW3f9vEDF3O2lqpD9AxfjO0ML8SgSevoHrmQuim72dLcTxTAug4DKgEDyDflhhJNEW/tx0snfImglbFyQ2svirMYTv58M5kQ6H7DMK7l8PKNApnzG2hupBDLtRSgTF6Z10JOMmefLZIQxEK3vE4oG6aHK+0YC2goPOlXGZMYFdtzJGupCpNljAcyS3LJ881qjxUhFvDwhHmItoSWaXWtdZhPYTvjjut/rB23gp4AyEAT8xPyIU0tuhRQkJIKjSASKzul2Iokkp/C2ZJlEoEw7jCuJ970kbS7jHXdVjuf80d4fGZmhSS8w+XQqX0NiMm6vwGmFUkyZflOeyCYmoe9d2EwTANpFSBkzmzJAP5YIIQ5BDCzslbG1Y450RGV1hMxrwIxJKpRMfS389ZXzbCwa5AfThKL7MPtV3Ao09wTKrHWVqgTNKsv4ApZ7kbOsH5TDklsu4/fEwrrFP3b0KrtWCXhnI6oh369BpVqNJm82Qn+nfpT6fyeh4F/Xo75+i/RwUGqcAJagQRez5aYUPuLG15ij8VankLlil7GF/QE5jaETTuRMeKRrHWy7DXozkVIHLMZHBxDG2evqJk0xdy+OiXvKBXamoyDlrMRjdNNW/4jhYI1elUCi4Zfc8a2+0B7pJ3nEzc6uuJQdEee6OqP59tKjsDDSdVBSA/XA26dGf9pC07Q+kXzaw8PycECTag03SIOqDtiKabxy+dM3/ot23EKca9BNC5FV+fIdMMSipnaeAEDvoY0VNKEPBs9mv2nmzCYdWVdUQOh7OTNO4YehLcoO0DZ4Rio25KOffm3CFM3nbg5LLxYvTqzH78tLpA299cm3 47ojA3MQ jz9B4/p5WjQkls5vcCzalsUaorz/6VbXxBABVD1sE0NHyJS4iSGrrVLa29ZA7UtTTkfYr/+VivBTo8q/unPKb0mHDDd7ccibxj3MYtCb0mTCvf5pVKXKs44Qb8yXPNbnCKVTgIjih4TCffrPqg852Yl2M7UlEyceWQK0DDCaobMLX1thYYL5vE8RyhG4VCw35bBuPibYwOtbHJ5JMK1E8RZ6tRLNTbXMML2sGxnnE+Z9JnRvqmRrrlW8BWwi8cZ7I4+zi+et/pG9SNMuaS1M8gokmwpUTr22fNv1OIzDIS5bfJdt4tb42izeftHCFul73nwf1EL9wjO8YkjiMi68RF9UzmrUMZGpjfZSE+Zu3ZtdqP+lz1hIiYOio0BlR7oxQmiZl2ZpKsFbMUN0Mnqfa57nZwZzKtj391tPHoH/AS1C/SQwj6Eb76bgu7UfhTJKgx5sdreZoD6Ym8N8vgFIm9aMRD19IkuVTqvGQ5ZdO0eesgz9O3WY3evGjLtYqdfiRd/QqEvHF+4TrNdZ+pA+tRfG7MfPyhI5aeYP2 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 Tue, Oct 3, 2023 at 4:22=E2=80=AFPM Yosry Ahmed = wrote: > > On Tue, Oct 3, 2023 at 4:14=E2=80=AFPM Nhat Pham wrot= e: > > > > For most migration use cases, only transfer the memcg data from the old > > folio to the new folio, and clear the old folio's memcg data. No > > charging and uncharging will be done. These use cases include the new > > hugetlb memcg accounting behavior (which was not previously handled). > > > > This shaves off some work on the migration path, and avoids the > > temporary double charging of a folio during its migration. > > > > The only exception is replace_page_cache_folio(), which will use the ol= d > > mem_cgroup_migrate() (now renamed to mem_cgroup_replace_folio). In that > > context, the isolation of the old page isn't quite as thorough as with > > migration, so we cannot use our new implementation directly. > > > > This patch is the result of the following discussion on the new hugetlb > > memcg accounting behavior: > > > > https://lore.kernel.org/lkml/20231003171329.GB314430@monkey/ > > > > Reported-by: Mike Kravetz > > Closes: https://lore.kernel.org/lkml/20231003171329.GB314430@monkey/ > > Suggested-by: Johannes Weiner > > Signed-off-by: Nhat Pham > > Does this patch fit before or after your series? In both cases I think > there might be a problem for bisectability. Hmm my intention for this patch is as a fixlet. (i.e it should be eventually squashed to the second patch of that series). I just include the extra context on the fixlet for review purposes. My apologies - should have been much clearer. (Perhaps I should just send out v4 at this point?) > > > --- > > include/linux/memcontrol.h | 7 ++++++ > > mm/filemap.c | 2 +- > > mm/memcontrol.c | 45 +++++++++++++++++++++++++++++++++++--- > > mm/migrate.c | 3 +-- > > 4 files changed, 51 insertions(+), 6 deletions(-) > > > > diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h > > index a827e2129790..e3eaa123256b 100644 > > --- a/include/linux/memcontrol.h > > +++ b/include/linux/memcontrol.h > > @@ -711,6 +711,8 @@ static inline void mem_cgroup_uncharge_list(struct = list_head *page_list) > > > > void mem_cgroup_cancel_charge(struct mem_cgroup *memcg, unsigned int n= r_pages); > > > > +void mem_cgroup_replace_folio(struct folio *old, struct folio *new); > > + > > void mem_cgroup_migrate(struct folio *old, struct folio *new); > > > > /** > > @@ -1294,6 +1296,11 @@ static inline void mem_cgroup_cancel_charge(stru= ct mem_cgroup *memcg, > > { > > } > > > > +static inline void mem_cgroup_replace_folio(struct folio *old, > > + struct folio *new) > > +{ > > +} > > + > > static inline void mem_cgroup_migrate(struct folio *old, struct folio = *new) > > { > > } > > diff --git a/mm/filemap.c b/mm/filemap.c > > index 9481ffaf24e6..673745219c82 100644 > > --- a/mm/filemap.c > > +++ b/mm/filemap.c > > @@ -819,7 +819,7 @@ void replace_page_cache_folio(struct folio *old, st= ruct folio *new) > > new->mapping =3D mapping; > > new->index =3D offset; > > > > - mem_cgroup_migrate(old, new); > > + mem_cgroup_replace_folio(old, new); > > > > xas_lock_irq(&xas); > > xas_store(&xas, new); > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 6660684f6f97..cbaa26605b3d 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -7316,16 +7316,17 @@ void __mem_cgroup_uncharge_list(struct list_hea= d *page_list) > > } > > > > /** > > - * mem_cgroup_migrate - Charge a folio's replacement. > > + * mem_cgroup_replace_folio - Charge a folio's replacement. > > * @old: Currently circulating folio. > > * @new: Replacement folio. > > * > > * Charge @new as a replacement folio for @old. @old will > > - * be uncharged upon free. > > + * be uncharged upon free. This is only used by the page cache > > + * (in replace_page_cache_folio()). > > * > > * Both folios must be locked, @new->mapping must be set up. > > */ > > -void mem_cgroup_migrate(struct folio *old, struct folio *new) > > +void mem_cgroup_replace_folio(struct folio *old, struct folio *new) > > { > > struct mem_cgroup *memcg; > > long nr_pages =3D folio_nr_pages(new); > > @@ -7364,6 +7365,44 @@ void mem_cgroup_migrate(struct folio *old, struc= t folio *new) > > local_irq_restore(flags); > > } > > > > +/** > > + * mem_cgroup_migrate - Transfer the memcg data from the old to the ne= w folio. > > + * @old: Currently circulating folio. > > + * @new: Replacement folio. > > + * > > + * Transfer the memcg data from the old folio to the new folio for mig= ration. > > + * The old folio's data info will be cleared. Note that the memory cou= nters > > + * will remain unchanged throughout the process. > > + * > > + * Both folios must be locked, @new->mapping must be set up. > > + */ > > +void mem_cgroup_migrate(struct folio *old, struct folio *new) > > +{ > > + struct mem_cgroup *memcg; > > + > > + VM_BUG_ON_FOLIO(!folio_test_locked(old), old); > > + VM_BUG_ON_FOLIO(!folio_test_locked(new), new); > > + VM_BUG_ON_FOLIO(folio_test_anon(old) !=3D folio_test_anon(new),= new); > > + VM_BUG_ON_FOLIO(folio_nr_pages(old) !=3D folio_nr_pages(new), n= ew); > > + > > + if (mem_cgroup_disabled()) > > + return; > > + > > + memcg =3D folio_memcg(old); > > + /* > > + * Note that it is normal to see !memcg for a hugetlb folio. > > + * It could have been allocated when memory_hugetlb_accounting = was not > > + * selected, for e.g. > > + */ > > + VM_WARN_ON_ONCE_FOLIO(!memcg, old); > > + if (!memcg) > > + return; > > + > > + /* Transfer the charge and the css ref */ > > + commit_charge(new, memcg); > > + old->memcg_data =3D 0; > > +} > > + > > DEFINE_STATIC_KEY_FALSE(memcg_sockets_enabled_key); > > EXPORT_SYMBOL(memcg_sockets_enabled_key); > > > > diff --git a/mm/migrate.c b/mm/migrate.c > > index 7d1804c4a5d9..6034c7ed1d65 100644 > > --- a/mm/migrate.c > > +++ b/mm/migrate.c > > @@ -633,8 +633,7 @@ void folio_migrate_flags(struct folio *newfolio, st= ruct folio *folio) > > > > folio_copy_owner(newfolio, folio); > > > > - if (!folio_test_hugetlb(folio)) > > - mem_cgroup_migrate(folio, newfolio); > > + mem_cgroup_migrate(folio, newfolio); > > } > > EXPORT_SYMBOL(folio_migrate_flags); > > > > -- > > 2.34.1 > >