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 CF9BBD339A9 for ; Mon, 28 Oct 2024 17:55:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 714856B0098; Mon, 28 Oct 2024 13:55:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6C39A6B0099; Mon, 28 Oct 2024 13:55:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 58B886B009A; Mon, 28 Oct 2024 13:55:07 -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 3545F6B0098 for ; Mon, 28 Oct 2024 13:55:07 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id E87FEAB7B4 for ; Mon, 28 Oct 2024 17:55:06 +0000 (UTC) X-FDA: 82723762002.29.75DA05E Received: from mail-vs1-f51.google.com (mail-vs1-f51.google.com [209.85.217.51]) by imf08.hostedemail.com (Postfix) with ESMTP id 6D035160008 for ; Mon, 28 Oct 2024 17:54:49 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="SW/F+jT2"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.51 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730138062; a=rsa-sha256; cv=none; b=03pQEP5562cPGK9AxPrvjpvU515tOOzz01eUFZUIGFDAO2LUs7Pfujjvo0sJreVof5bjzg PaDZ0+c611t0p47yqIsODpGfE0PRMU8Ze+X/mfLU/mIyirIPabsPW3nttQThoU4L7GN72T szkUr0p5AYjxUMpEdYobjFjidMnGIm0= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="SW/F+jT2"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of yuzhao@google.com designates 209.85.217.51 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730138062; 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=76NEiAhCULKghHCOTi8HEn+XigOAhX13pYtFw/tq9FM=; b=3B/XSp7L28DTEwOE32rOxpFuKch58uOcNNvwa9zRmw8CgmailMraqUSesGOaXA+gHogdZh 6cPhpn3vBIe7Let3BcZ45d9AyrIvdoiKcwjPv63nPMCQSE/KcxBLXIqgHak1ZBsLcklArr Y8mQzmWBXMro4vKTueIdEIsMtnTJRHg= Received: by mail-vs1-f51.google.com with SMTP id ada2fe7eead31-4a46fee3b16so2190475137.0 for ; Mon, 28 Oct 2024 10:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1730138104; x=1730742904; 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=76NEiAhCULKghHCOTi8HEn+XigOAhX13pYtFw/tq9FM=; b=SW/F+jT2xtKF0OG4kEWtrJz7wMQJLzyUcl5PvhullBKtHaFGcVA5JM8VZfbfDZpj5m 9s++rTW/xfqyEF7Aj44KYxOyHUn81saCKJJfVYXK08nAvl4Vx9aiJBHsZR1SYS/X2ddq oUzA8b9bOBgGdCxlKwI69Zzn+4CgXaas2ivXtX4Onmz22UuCNnl3JPu/iki1MWQCXZWh jcaqBRiVxGTYU3XN9NXek7loT11vAbfy3Gv9T7c+MhNdZe5W5ho0svGDSni1qd54WFuH V3G+H2dnz3chwCiJnX4mX01+z788JhKcEZvBeDAmVjntXzSSL67EUzByLcAyBPghE+fc udew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730138104; x=1730742904; 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=76NEiAhCULKghHCOTi8HEn+XigOAhX13pYtFw/tq9FM=; b=TvWQgQ2yXNFHjbTjfJ4YcrAxqWwa00h2goPjBulck6HNyM8xzom47wCY8+Lj4l1Kdj Kl0ABAQqX3+qq0OZkE+82LQFVLHVycHPCPN38vPlvtk+UL+kZELlAsRx+ZxMDEVLr/5F wtQC7rNFP4YIfPaceI27SzeQFw9n8HcTKaRD8mjQGqQurm24TblgBtdBLZLgrrlNC+CC SpqcBlg/P+57j1bECcn92EAzU0x3UVcu8uzKtL/8+UcRqo6ctGKfmb8quXP/h+4aAnlj OMuw1RuLw4be2ZfCT2aZZHDNX6ObVqM37ZkKisfdxo2fVJYKSot/U5K8vSH1kWjF75Gm sAbA== X-Forwarded-Encrypted: i=1; AJvYcCVKCp1fYLED4fNpbynvASVmVAyuGEvzwpC1eLCQ/qPebwDpiZrMMlFcijtM94NkJFskEUM+vnSNhQ==@kvack.org X-Gm-Message-State: AOJu0YzWGo/ZaM0b8fKXsFCyKGL2F/gfrVpSKsdvSgs22qEfW/N3dsYq DlqXGQm5oZiotRAUEUx7lj3Bw8IhBlz7JwbOMAKaHZyW3YHbivi6U6YzMkZAuvgr2U5NpXvA5xh HuR7gaTltts/qwlznE0U5giwi6fBEmWQk5Uf6 X-Google-Smtp-Source: AGHT+IF+Njw3B2yyWa+PFr05ljvRcXvEMDxqBd0fMPaxgVP5hF0UW3Sx2OmvHFr28RqI1EbvlEOTgzarr1bO+bd/VqY= X-Received: by 2002:a05:6102:2908:b0:4a4:97d1:ae99 with SMTP id ada2fe7eead31-4a8f2bdf107mr547802137.12.1730138104112; Mon, 28 Oct 2024 10:55:04 -0700 (PDT) MIME-Version: 1.0 References: <20241026033625.2237102-1-yuzhao@google.com> <37a28ef7-e477-40b0-a8e4-3d74b747e323@suse.cz> <8459b884-5877-41bd-a882-546e046b9dad@suse.cz> <6ac7a38f-30df-4403-8723-a43829bcdba5@suse.cz> In-Reply-To: From: Yu Zhao Date: Mon, 28 Oct 2024 11:54:27 -0600 Message-ID: Subject: Re: [PATCH mm-unstable v2] mm/page_alloc: keep track of free highatomic To: Vlastimil Babka Cc: Andrew Morton , Johannes Weiner , Zi Yan , Mel Gorman , Matt Fleming , David Rientjes , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Link Lin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: riaycpzu461rrf8zoeshnkx7fgb86mqm X-Rspamd-Queue-Id: 6D035160008 X-Rspamd-Server: rspam02 X-HE-Tag: 1730138089-451063 X-HE-Meta: U2FsdGVkX18KxAKdJRY2fdKRLiouxoblcQ9W8taHDgzZ5/F5xbF1F7NcpFUcbuN5VjrtyFX4yOq4KnY057jHAxWx/XoCTp6JUPwb1Lja8H/AR06k+VDRRbGQhPuq6WtbR82T4aCbiFNP3TrIA6lwcnSGNblTBK6a4nTiKaLt8BXf+/TCqT28G0sqmDcWPldZEBez/YjZvWNeSVXNx78EoqpDW4+I7xw2+C+ToIYgrQH0LP/wAJBztABkbFH+gooMpxKTkvQtZuazWaMLUgD4NNlDLz15aIoLTUQ0zt9UvZEJBNEeCDW3FgEKkGD2x4YBv+WNBWzZruBDHIZ/TNE8EekvbPKBEg6YpTCKcKGRwrfmHf3rBgNNvu25F7fs8E7QicdFIBBlKJm9EAC8oiFdWfYfv1lualfXDZM4bBL93Txn38c+5opxwpTfRkfJS2JZCv0fUoH8m58O4BY76Qk1crkm8w9Qz8+rk+7j6qgCglZk4+cjn+afpJTh9OGXsPpuId3842G7nQt7GM/Qp3dI6+T6Hwl+TikyAsBbuw/YcnwS8InGTE3wDFSnSBOYmGd8TAp1VSnG/SD1xOlfKx6L5o5sKpWNXfp9aHp69B8Uq6ARWO6yph0fI7aybjn/qFk0jsXJFfXfmm4tzbaNRTNCJCW1EUvgc+Ygj9CzNauj1B5XiBDMmnw0GrxUhAMhncCKk9nQVLLKWkMyJsG1U3ZQtb0ougPg5/yDNwPXARtdl6CfVLPdtFBSY4Cst5WtGchDgQwp7Pz5Q0mvM9gQMbPsqS+MuUhPb7W0FLzVWTknFZguEehQ4DCAvB8JRv62lVKkGXhlms8jx9kkU+ll25lh7iRgstUbC71jqk8HAPAwf64tX6HvRLnI+CJcXvqoAA/vd9hwQB9PH+ejCnoGAsI0yRNv1P8eiNxr1j5K4ZgY1rVQWXvAPPghbPMhanVLRMK39nrgxaLrAMxLsgWIVAh N8vT+lmi 9+BnvV00CUv/++vhFbnRUyDqGsq7MDS6z9tDSg+56NKlMD3IjBAboVbVaKFXCkWa2DoKTWMr5ohzHOGWUhTokpjIn72Yb33wh46SdpCpGOBHgyCiFRzyl5M/xXQbQ9JMXj1PETl+rEwxMb2MqG/mBhM+danXbYpeqdczSLhHlb6pC1vhna932x3RczGi28Sgyw9bZ1cPzKt9dE9OcLzkrL5zhLEsPrg+8KG5byVa7+rk0CMVgos248JpsZA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000505, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Oct 28, 2024 at 5:01=E2=80=AFAM Vlastimil Babka wr= ote: > > On 10/28/24 1:24 AM, Yu Zhao wrote: > > On Sun, Oct 27, 2024 at 3:05=E2=80=AFPM Vlastimil Babka wrote: > >> > >> On 10/27/24 21:51, Yu Zhao wrote: > >>> On Sun, Oct 27, 2024 at 2:36=E2=80=AFPM Vlastimil Babka wrote: > >>>> > >>>> On 10/27/24 21:17, Yu Zhao wrote: > >>>>> On Sun, Oct 27, 2024 at 1:53=E2=80=AFPM Vlastimil Babka wrote: > >>>>>> > >>>> > >>>> For example: > >>>> > >>>> - a page is on pcplist in MIGRATE_MOVABLE list > >>>> - we reserve its pageblock as highatomic, which does nothing to the = page on > >>>> the pcplist > >>>> - page above is flushed from pcplist to zone freelist, but it rememb= ers it > >>>> was MIGRATE_MOVABLE, merges with another buddy/buddies from the > >>>> now-highatomic list, the resulting order-X page ends up on the movab= le > >>>> freelist despite being in highatomic pageblock. The counter of free > >>>> highatomic is now wrong wrt the freelist reality > >>> > >>> This is the part I don't follow: how is it wrong w.r.t. the freelist > >>> reality? The new nr_free_highatomic should reflect how many pages are > >>> exactly on free_list[MIGRATE_HIGHATOMIC], because it's updated > >>> accordingly. > >> > >> You'd have to try implementing your change in the kernel without that > >> migratetype hygiene series, and see how it would either not work, or y= ou'd > >> end up implementing the series as part of that. > > > > A proper backport would need to track the MT of the free_list a page > > is deleted from, and I see no reason why in such a proper backport > > "the counter could drift easily" or "the counter of free highatomic is > > now wrong wrt the freelist reality". So I assume you actually mean > > this patch can't be backported cleanly? (Which I do agree.) > > Yes you're right. But since we don't plan to backport it beyond 6.12, > sorry for sidetracking the discussion unnecessarily. More importantly, > is it possible to change the implementation as I suggested? The only reason I didn't fold account_highatomic_freepages() into account_freepages() is because the former must be called under the zone lock, which is also how the latter is called but not as a requirement. I understand where you come from when suggesting a new per-cpu counter for free highatomic. I have to disagree with that because 1) free highatomic is relatively small and drifting might defeat its purpose; 2) per-cpu memory is among the top kernel memory overhead in our fleet -- it really adds up. So I prefer not to use per-cpu counters unless necessary. So if it's ok with you, I'll just fold account_highatomic_freepages() into account_freepages(), but keep the counter as per zone, not per cpu. > [1] Hooking > to __del_page_from_free_list() and __add_to_free_list() means extra work > in every loop iteration in expand() and __free_one_page(). The > migratetype hygiene should ensure it's not necessary to intercept every > freelist add/move and hooking to account_freepages() should be > sufficient and in line with the intended design. Agreed.