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 B2CB2E75455 for ; Wed, 4 Oct 2023 14:17:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 171128D009A; Wed, 4 Oct 2023 10:17:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 121368D0027; Wed, 4 Oct 2023 10:17:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F2BB28D009A; Wed, 4 Oct 2023 10:17:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E57328D0027 for ; Wed, 4 Oct 2023 10:17:24 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B76B08019A for ; Wed, 4 Oct 2023 14:17:24 +0000 (UTC) X-FDA: 81307981608.30.E04BBFA Received: from mail-qk1-f174.google.com (mail-qk1-f174.google.com [209.85.222.174]) by imf24.hostedemail.com (Postfix) with ESMTP id A731A18001F for ; Wed, 4 Oct 2023 14:17:22 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=0PFps5pS; spf=pass (imf24.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.174 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1696429043; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0iVKRRlivbZawLpQE+aqhCrFfCHAJWFRH4b1xYHHXmU=; b=ntdQ72FvpbsCqWUYd7MSGu7U1v4AqhrAy/fxLNMAe9/UDiQ+o0zzNM3lpiD/uQQDjPOI4M yqSp5g3j0CIjOmKn/Il4t+yGOGN3y2+uNX74xaw5t3vnNTPi7v8X5n0IgdJnFZY2QKjxtW V/o3PI/MJE5s9uEyPQxvY6XLWxBUTfU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696429043; a=rsa-sha256; cv=none; b=R1Fq36kmuiC+l6RZo38WuF99Ze9fMtHlaFYxSsCZe0L+5wC167P0+4SonJIqgOPgIC6UNe rCq3BHR+FZef6OgbRGmbyp77IEhEwBNkLVyjB06hTwFhDUnSw8pVMmU6hEphsw4GWL2Cak SAR06cDFiUYT1tsE/Fdwf1o1uMSmFGM= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=cmpxchg-org.20230601.gappssmtp.com header.s=20230601 header.b=0PFps5pS; spf=pass (imf24.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.222.174 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org; dmarc=pass (policy=none) header.from=cmpxchg.org Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-77574c076e4so151355485a.1 for ; Wed, 04 Oct 2023 07:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20230601.gappssmtp.com; s=20230601; t=1696429041; x=1697033841; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=0iVKRRlivbZawLpQE+aqhCrFfCHAJWFRH4b1xYHHXmU=; b=0PFps5pS5+wrCzxXLagL9ott6aQMPlJGh5izPS9/h2tRnqI2BYY9pyuwXMR2mNz/7S x/lvGf9iZqPUZJtNoMYuvtA1D3HWGE3qqJG296xH1uDQOoeit9NNga48JywxrY852arV dl/68vXfWkaa/Ght76CncRQgjmTp5oXAAXf9jlHZN0HIaRs22+meH7508AxZ4cKNjZTh jm92oAN6m5dBVtwkxOELU5RPccsF1uTt0T0ZSqf1tesh5YdMg8rAMNoYxEPrDbwDMSo+ TccPG1GMtvUQexDQ4PlWgwq9lFbIdVPlKSMgj1J2Lo2XFjeAdGRj/nt9xanok9BACjGa ZpgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696429041; x=1697033841; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=0iVKRRlivbZawLpQE+aqhCrFfCHAJWFRH4b1xYHHXmU=; b=HcKNXYNdypRrazK4Ota7EuFb88Uog0OR9aoLfMTp1XQlA8+FqHOl61Nyd8yjhowY5S p+t7v2kHGcKaDlM/j7XdfmlmQ7QjBXjVU9O5iPJeuljNua3zO8B5T50u13/2/oirW0Lu RHSmj+WjyjWWq+H4X3P+niayDX/MpdiX3K0d2s1m8E8Sh7XVwMs2UcXGVD03gcBkXAoO JIxFQXRKWGb0BhD1huyZvHAmYiiW0m2eKW/t0sLoWaU40xPoOphqMDi0ZvNqs0+RjlbA CSng2Hmsnnp9LC7Ku5S6QKm7pllUB2VFNtOXPAxAxytH227fzAwVa5MmnV1sqfrTC6FQ KjvA== X-Gm-Message-State: AOJu0YzpWbTeWUVeDbWRFsttZ0X1W5EvSZ9KYZ07JoLn3A3RfR7u7X36 gEM0mzg7h+kI9JaL8odpnahgdQ== X-Google-Smtp-Source: AGHT+IHwbweLrbblB6DFXPXXebkAKQNIMi3Tti+rzdpJw79HDk06ZZMQubaZZkRYtiU5APTTeVDCUg== X-Received: by 2002:a05:620a:454c:b0:773:b623:72f7 with SMTP id u12-20020a05620a454c00b00773b62372f7mr3286274qkp.50.1696429041546; Wed, 04 Oct 2023 07:17:21 -0700 (PDT) Received: from localhost ([2620:10d:c091:400::5:753d]) by smtp.gmail.com with ESMTPSA id g23-20020a05620a109700b007756736aee0sm1280773qkk.115.2023.10.04.07.17.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 04 Oct 2023 07:17:21 -0700 (PDT) Date: Wed, 4 Oct 2023 10:17:20 -0400 From: Johannes Weiner To: Nhat Pham Cc: akpm@linux-foundation.org, riel@surriel.com, 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, yosryahmed@google.com, fvdl@google.com, linux-mm@kvack.org, kernel-team@meta.com, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Re: [PATCH] memcontrol: only transfer the memcg data for migration Message-ID: <20231004141720.GA35281@cmpxchg.org> References: <20231003171329.GB314430@monkey> <20231003231422.4046187-1-nphamcs@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231003231422.4046187-1-nphamcs@gmail.com> X-Stat-Signature: aenyo5tjqiqdwydh1wqnsumsbqrgf8jw X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: A731A18001F X-Rspam-User: X-HE-Tag: 1696429042-896983 X-HE-Meta: U2FsdGVkX1+Pb22J4aZx8tjLE02l07kBvIqPdGQ94hBTP+Rr5/p9FC3SjfV8B5aruLYJA5ZsHvwQKcoQs5zPOpcI4szUX00NodhWJii7CAHD/b9W1UiV2riUn5wXoY8RunwM+wWNzbOY+9nBWk0sFsYb6sm73lZaSAPor1p4+/u7RDP/3d7k1GFqC0bLWLpSm3pswkqLqjMhpEbYoEtb0lzItbRs2ueieKxL9ePjP7wEPT+e9FgwTRb/bUwSJStjY5AHg35ZUTLkVrTGXc2c2AVc+AriiOi8TizMlgJQoQgBayv7yngvBh1L/QmdkKmVrWX68JIUKIe+RJCzd+mCGBugea10FrfWESe9NcuDtYY4tm/DyMbrH6Aao0+9hujdlS/zhTQzlpqotY9jKh/u0btl27HaaF+qhNHVxuFCJzQIs5GBbJZxDF516CqUauZmB+xzCEUQBgks75UYoFeX+SoKJ3k60IQBecmFnRQ40nxL4uYnILWr5sheab5aLLsL6kAnTpJIs8TNPaCdcDC5z0EYMkSvL+TXYVmLpACwRaGYa+uIjp+1CI4Q3VfA2jJNv/ifAcV6BxRt/OD+Y0Sh9ZWFqDRpndWt3dmb/ZHr/LP2MBVsISvueX101F+YSfgp+8L0H/cmfHXXDDSA2JFYrYADLX1/aNzEthwUj8x4al/Ms67paB3FBoUe/4iOhJQ3Wf1hFIL0hYAgqN4yCzBqi0ZxWW0pEVUjr4hOkbM3UJDrrWIWs2K/NW2B2Sn8O/ZKI1HSCjAvCDRSvoF9IyTfdaDmd1bAMvNG3yC5sdqb/XRTUHXY6UG9U+4ovejcRzkQlcg2xg2Mgog2R+y1tnbYJ0xpR+ln1Xj2vEFBF6yJw4rfg7TkWTuNV0JtZZu2LmPpIl6EeecarNhRxjTDEMTloNd/RT5QrCOTBuYMe8E53pMAzDilm3dqQtrakrX62aNHiX1F5T7zouupPLK1DJa OKaNBUY0 cCQT0wRNa1bPzBLT9DokFevQsu9lPBx7b7K135Ce9iVYbGXD8D8ozoZH9awMIrYr+9VqNAnEII1W9LBGTOFqresJEAvUb50wyB9wvn6OGP6Ay9nlEe1a0Ku7plhe4U1Jh7611Fonm7alrcEVBZmhbvp+1OR2iMZ5wP/foQ+mzi2ErQ2LeJiGiCwPb/twWRE4jkJTwdv6CRVvSMKRRFasovVx2DylapQ2OL2d4efFhK9CZ1/P8eusOnlBEWKivsbA/oq4+HdFSSaOpt8VCoN0F0pD9o4Vi1bEDcUJ8sA0/5V+VSEsPPVNnKonrnvoRcRwG0kjSkR4NJPMIT3mf1quAsijWF7NmEa9ca5ejH9fSt5qMQ/t4Eo2pBuKD1Bcmclk+oIiUm2bn15JR9sDXe4o2pnhLKre0wdFrlOBN562jIkrKgFsi63KTl9LDiqF4Q1NWKJW/faFJNGc6pYsLW3ojll5UutQDWAalgJLzrKFyoMwULaoVFfs9YbPyi6v/jazh+7RzuiNp3zTnY68MYcIHba6mHNVirIZ3JcQry1JB4BbEI//As5g8zsJLZGv5UigA9Kfkc7NcA37uR2k= 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 03, 2023 at 04:14:22PM -0700, Nhat Pham wrote: > 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 old > 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 For squashing, the patch title should be: hugetlb: memcg: account hugetlb-backed memory in memory controller fix However, I think this should actually be split out. It changes how all pages are cgroup-migrated, which is a bit too large of a side effect for the hugetlb accounting patch itself. Especially because the reasoning outlined above will get lost once this fixup is folded. IOW, send one prep patch, to go before the series, which splits mem_cgroup_replace_folio() and does the mem_cgroup_migrate() optimization() with the above explanation. Then send a fixlet for the hugetlb accounting patch that removes the !hugetlb-conditional for the mem_cgroup_migrate() call. If you're clear in the queueing instructions for both patches, Andrew can probably do it in-place without having to resend everything :) > +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) != folio_test_anon(new), new); > + VM_BUG_ON_FOLIO(folio_nr_pages(old) != folio_nr_pages(new), new); > + > + if (mem_cgroup_disabled()) > + return; > + > + memcg = 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. Is that sentence truncated? > + */ > + VM_WARN_ON_ONCE_FOLIO(!memcg, old); > + if (!memcg) > + return; If this is expected to happen, it shouldn't warn: VM_WARN_ON_ONCE(!folio_test_hugetlb(old) && !memcg, old);