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 2FE9DC4828D for ; Sat, 3 Feb 2024 04:18:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 708356B0072; Fri, 2 Feb 2024 23:18:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6B7D76B0074; Fri, 2 Feb 2024 23:18:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5586D6B0075; Fri, 2 Feb 2024 23:18:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 46F786B0072 for ; Fri, 2 Feb 2024 23:18:00 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 0FE3C1A0108 for ; Sat, 3 Feb 2024 04:18:00 +0000 (UTC) X-FDA: 81749184720.25.3EC659B Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) by imf15.hostedemail.com (Postfix) with ESMTP id 523A5A0008 for ; Sat, 3 Feb 2024 04:17:58 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TqflbxI4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=ioworker0@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706933878; 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=nsl3WqQ+k+ykbNiLwPF1PCJ3ZiKDT5+I14JPm9QENBQ=; b=Lmzv2IDORgDMnBxdYOxlqG67UTlqsqyBQJY0c4npqpAtv/xG55bu8w5tQ3EAb4XWCrz1FZ G8R9grb9kL8aX7OkVOeSEEcdcDR/N+ftz1KGJFx8Ef0DMxDDbvIXsDsswdYxhcx23wjjrU v+Xt3xcoES3jQmuVy2zOVUCI6v3Qeo4= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=TqflbxI4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf15.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.219.174 as permitted sender) smtp.mailfrom=ioworker0@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706933878; a=rsa-sha256; cv=none; b=B2sa6q3626Qfzi4tsPXkSHh8248UDu08IuUUGq79+wvD7QHDhU75PPd/zZfCneLSoc3k6s O8/qFwGth1u697Oj3UuvN8mQ47bVy69uLO412nbF5NrzifogpRJttfqbzby3mXd5Ha8huQ 0auRqXUoUwSPcETkNdVDxDMOpeUf/nI= Received: by mail-yb1-f174.google.com with SMTP id 3f1490d57ef6-dc25e12cc63so3303844276.0 for ; Fri, 02 Feb 2024 20:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706933877; x=1707538677; 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=nsl3WqQ+k+ykbNiLwPF1PCJ3ZiKDT5+I14JPm9QENBQ=; b=TqflbxI4HbhqANqcX8i0alRUV3N2DiOy4pJYCBDui5JAgVjtZhgoad87vRyA1SIwRp 0Y5lFcUemKMnt1zSSN2htD1zdPZ5+kBrA/eCMwkChK+2t85v+TzKjkf79nRB3KCZ/J1N KO9BhNH3mfadCKRGcjK98Hw2qhtcsVeyLz0WwbDFs6i+dW3z08NzJcZlynnePUduVnK2 /SLauwSitsObwWMiwdyEu7J/zBtMpJ7/Sz8fvtpMvQ8mHsc2njM+GaWphjHaW6KD/YXl K7qDj1UwGprO65nsfX/KZCpdojvrjEQVp9n5F6OYtmvjRtQkqUusI7RdJFNjx8DBLWUi kKYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706933877; x=1707538677; 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=nsl3WqQ+k+ykbNiLwPF1PCJ3ZiKDT5+I14JPm9QENBQ=; b=mmmsttcXQyzPKNYrqJvYZTzdjEMFer8k3J08XOVYq98UG0f/3aR/+fG5zkHN+Zbj3A LdeGZsjCgR8BngLw6ihBxgpqXQCNH+cgQKEXyyXlNhAu01Mf82oxdL1hX42fG6xuh20s y/pba45WMpu7P6qz9qQN/n851vEwuT0EOwQA9hXouggbOztdC2gn8n6hL/ETnq95ZBya TNPvWAUJIz8WhZqwBBErwR4GwF2V+2QbCvGKlxJl9cDhwM5xnTBIpvZJcQbDMcCnLO0p HYmRSEXjHTXboEu1G5dYenoWIHEY9CnEt0rRngKYFf89nVIWacV9efFaerplxDZEdSU4 Sk1Q== X-Gm-Message-State: AOJu0Yy4bHiwlIpKgwLtLGNp7wSthVG84E8+22/rhLpgIGd9LXbYJpOY lpC5Mi2uRzP7cUPUgoTTWlgFPcNbXneXUi5NTLWeB2pSkd40KEA0CnfhrtJ7XAOW2WZWMOmM2gd osO4DpDGJPTlMUxZj2hHd1Dhom7s= X-Google-Smtp-Source: AGHT+IGDes7I6Lw5tNAKr41vy3Nm31KZ13xinGdJaeNu3Cj+y1qeCO20pV70xsfUrp9HTXKQPWob3FOvoTdbhzTRNRw= X-Received: by 2002:a25:8183:0:b0:dc6:5570:898e with SMTP id p3-20020a258183000000b00dc65570898emr353556ybk.17.1706933877392; Fri, 02 Feb 2024 20:17:57 -0800 (PST) MIME-Version: 1.0 References: <20240201125226.28372-1-ioworker0@gmail.com> In-Reply-To: From: Lance Yang Date: Sat, 3 Feb 2024 12:17:45 +0800 Message-ID: Subject: Re: [PATCH 1/1] mm/khugepaged: skip copying lazyfree pages on collapse To: Yang Shi , Michal Hocko , David Hildenbrand Cc: akpm@linux-foundation.org, zokeefe@google.com, songmuchun@bytedance.com, peterx@redhat.com, minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 523A5A0008 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: ws9kruf1kpzf6ysdnchmq3as6468g3ze X-HE-Tag: 1706933878-967110 X-HE-Meta: U2FsdGVkX19scS21vpDlSnMQzPxqli6Nn1u+fmG0Q4hgLf/XL1wNivA1Ab8+Hm17YrjisfNMkuFXs9V3edF1IWdVNig3OOVbVe4uhvoBMMqkMY6ttXzeIawYVvc6KN+LXtBlU4vh2igjWFQYWxlbsQ3iRZ4I8nuBECwo9uT8secmH3qIEeAodDmokMK0YOD1H8Iq26L0p2sgWs3QLd0fta61LthyCfWPzqIyVC2A46G9o+42j2uD1PqALi8d+eqsYCmgEejMtXFrKxW6IxuJo8zYKQJf3wzZq+UXg//LvKnvd/K0L6XPUD1d7nF1qIRvQCUYXU2ME6H352teUF/3r55bSC+k2LLngIEr8/nSob6cNj4jAe5q/StIYu81hKHB3uVbbmcL5KWknOyuOO8FoXmqHbyknYfwy+SHgMVWCqJKPPloSmq/Xbz+ZUwfZayWyskmn2+ZVoKlOEjJs0SrAMEPTOjR4E9VSH2rD8gkywR9IPAmpyoXxlVVzf/SCGxfJTu/bJ7ziOGZ9n7NdDqmcE2gpOAd4zj7fimmJFxMEC+ypQfXtBpje8sGDOAc6cmWHvY7HpPCHiu2p0qh2L7Uny0VKEczcUpjgVRYpe9UtSUguOEs6UBjgmadoy4VFS3NzWzo3RuL6ORchm5xc2YBFfDwAqUh+q53VPS8oBXmJtnOD4VK0r7iIbq7QWh8teK6poJc23TzO3Cmu0ROMj15UdpDeSrW6xoFnFdKyAMdwc3dG4SibsARvKbazF+dGp74gkxQ/4i3TpRaPdKqnJk9U49AtO0Fno+pfDV3jrPdJEaAkGjadwotwT0xd1lw3Z2AbllbuNKSP8FZhr/AE+mXFkIHYa2kdOmKdkHZaIxX+Ihe0Mal7sVNmNWN8RI2NGYVIthv2GYiP1E0LleRIbiCywQubnFrSwiPyhcygTwbsgRKnqkflSwDTp92A9OfL6twwyKDDSrKnma3zzwZ4D/ KSJXCawY ERj092q68OibW04MFj3BNBTr3uP7PJWiamnTYqZ827siY5EMAiIbhDaTCGdMPe+hAHuiq90DXH0yEKKOjPeyU5/9d0upqVQoH2E+bQpGnEvuHZL45Zki+8wAz1ZH67r9oc116zJZeZdVArePh77CjCZhqGqpsyBzEQCTWweDUM+JNwXQ1aJTXWt3R3XAdOLvDwk/gfyIKdBTADSoPRsxROLgMktqTL+eRxDvD5TJ954wvtVSGCE/KzX1M07rdKhnKtfkP/TW3UlMjjzzYOtQFZS2tAb71xpRhQaJrIcrKgMGxTrkTx2N10w3ZRyaf9Sge8p4t8zgObmn/jsQp1YcSmKKFL6MIrLYiYe404J/PQehs4SAzlf74mAjhd7t2pvMZDrwmor6yxMx4V0IV8w20ZGymwgKhXE+3v20ZFwg/OvqyfsTxAvuOEkxsRw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hey Michal, David, Yang, I sincerely appreciate your time! I still have two questions that are perplexing me. First question: Given that khugepaged doesn't treat MADV_FREE pages as pte_none, why skip the 2M block when all the pages within the range are old and unreferenced, but won't skip if the partial range is MADV_FREE, even if it's not redirtied? Why make this distinction? Would it not be more straightforward to maintain if either all were skipped or not? Second question: Does copying lazyfree pages (not redirtied) to the new huge page during khugepaged collapse undermine the semantics of MADV_FREE? Users mark pages as lazyfree with MADV_FREE, expecting these pages to be eventually reclaimed. Even without subsequent writes, these pages will no longer be reclaimed, even if memory pressure occurs. BR, Lance On Sat, Feb 3, 2024 at 1:42=E2=80=AFAM Yang Shi wrote= : > > On Fri, Feb 2, 2024 at 6:53=E2=80=AFAM Lance Yang w= rote: > > > > How about blocking khugepaged from > > collapsing lazyfree pages? This way, > > is it not better to keep the semantics > > of MADV_FREE? > > > > What do you think? > > First of all, khugepaged doesn't treat MADV_FREE pages as pte_none > IIUC. The khugepaged does skip the 2M block if all the pages are old > and unreferenced pages in the range in hpage_collapse_scan_pmd(), then > repeat the check in collapse_huge_page() again. > > And MADV_FREE pages are just old and unreferenced. This is actually > what your first test case does. The whole 2M range is MADV_FREE range, > so they are skipped by khugepaged. > > But if the partial range is MADV_FREE, khugepaged won't skip them. > This is what your second test case does. > > Secondly, I think it depends on the semantics of MADV_FREE, > particularly how to treat the redirtied pages. TBH I'm always confused > by the semantics. For example, the page contained "abcd", then it was > MADV_FREE'ed, then it was written again with "1234" after "abcd". So > the user should expect to see "abcd1234" or "00001234". > > I'm supposed it should be "abcd1234" since MADV_FREE pages are still > valid and available, if I'm wrong please feel free to correct me. If > so we should always copy MADV_FREE pages in khugepaged regardless of > whether it is redirtied or not otherwise it may incur data corruption. > If we don't copy, then the follow up redirty after collapse to the > hugepage may return "00001234", right? > > The current behavior is copying the page. > > > > > Thanks, > > Lance > > > > On Fri, Feb 2, 2024 at 10:42=E2=80=AFPM Michal Hocko = wrote: > > > > > > On Fri 02-02-24 21:46:45, Lance Yang wrote: > > > > Here is a part from the man page explaining > > > > the MADV_FREE semantics: > > > > > > > > The kernel can thus free thesepages, but the > > > > freeing could be delayed until memory pressure > > > > occurs. For each of the pages that has been > > > > marked to be freed but has not yet been freed, > > > > the free operation will be canceled if the caller > > > > writes into the page. If there is no subsequent > > > > write, the kernel can free the pages at any time. > > > > > > > > IIUC, if there is no subsequent write, lazyfree > > > > pages will eventually be reclaimed. > > > > > > If there is no memory pressure then this might not > > > ever happen. User cannot make any assumption about > > > their content once madvise call has been done. The > > > content has to be considered lost. Sure the userspace > > > might have means to tell those pages from zero pages > > > and recheck after the write but that is about it. > > > > > > > khugepaged > > > > treats lazyfree pages the same as pte_none, > > > > avoiding copying them to the new huge page > > > > during collapse. It seems that lazyfree pages > > > > are reclaimed before khugepaged collapses them. > > > > This aligns with user expectations. > > > > > > > > However, IMO, if the content of MADV_FREE pages > > > > remains valid during collapse, then khugepaged > > > > treating lazyfree pages the same as pte_none > > > > might not be suitable. > > > > > > Why? > > > > > > Unless I am missing something (which is possible of > > > course) I do not really see why dropping the content > > > of those pages and replacing them with a THP is any > > > difference from reclaiming those pages and then faulting > > > in a non-THP zero page. > > > > > > Now, if khugepaged reused the original content of MADV_FREE > > > pages that would be a slightly different story. I can > > > see why users would expect zero pages to back madvised > > > area. > > > -- > > > Michal Hocko > > > SUSE Labs