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 41B46CD1293 for ; Sat, 31 Aug 2024 10:49:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 636DB6B0249; Sat, 31 Aug 2024 06:49:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BE7E6B024A; Sat, 31 Aug 2024 06:49:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 438366B024B; Sat, 31 Aug 2024 06:49:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 21DEF6B0249 for ; Sat, 31 Aug 2024 06:49:49 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id B44B4120B35 for ; Sat, 31 Aug 2024 10:49:48 +0000 (UTC) X-FDA: 82512220056.06.BE9A6F4 Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) by imf21.hostedemail.com (Postfix) with ESMTP id E09211C0004 for ; Sat, 31 Aug 2024 10:49:46 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=IR6k0lgF; spf=pass (imf21.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1725101314; 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=PLlRZBudcu0lYfVZFrWfCDmNfufwcjnWFsmygXQl1x4=; b=WZsGW0yPLd98sn1RjIVr8E+CdmMI9SAqiaBbQjJr6lYEcisuyC2LHczAMrNd7PuzLM562z Sh+F1Z8ZiClrxfEzMXr10ADnwOycjOSwZ/jtMkAWMc7STwyHETVP3sRk48eFdRAoCJpJVQ xOv0Yi5HdIaAsD0WCNWyWfgpTXbYY2M= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=IR6k0lgF; spf=pass (imf21.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.48 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1725101314; a=rsa-sha256; cv=none; b=oCLTfplICu2bm3rOo1ZzcmiZrQspMREJfeoEyFfVQL0JC25jZHUH9hbdWnRQZ/rXVEZLv4 JrcNPgUjkCUNxFJe6qpxfumZ8UTr5lWuVYdhTfkhzILb390rgAhbbqpZyNaIgZrH7wNp7Q 3o3Uei146lVYmsYcpit1BLBKcFD/9bY= Received: by mail-vs1-f48.google.com with SMTP id ada2fe7eead31-498d14b9b8cso840952137.3 for ; Sat, 31 Aug 2024 03:49:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725101386; x=1725706186; 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=PLlRZBudcu0lYfVZFrWfCDmNfufwcjnWFsmygXQl1x4=; b=IR6k0lgFMdHLSJt5taZ8QI3pZfXvPFqMq7oUMHRmL69pMyPWYS+1/9a3su4KbxTXeX 4c5i5fCZwQZaTSQ7Xhzf3UyypIWY+Q4ik+abwGIs5gxGtcWO/olmCyvvGzEW3i+bgZ11 iSyuYoABMWtz5zwyMFLtjnJQM9fCw9bWwyklT+zt53lSHVl9Ha558kisGJPGO4iL43PE tpl6rSBy70AvKL6Rm0Rcl0RSh8VfolqcUTUP6Vxq/aRBwLCh6l22UxexQwMB27zPuq7T R0KPpzWjyKoY2Vv+vYmBR0jxumSipYtMz3sTgcY3WDumx+aqXAWgWeh2UrdrTiZgDGG+ WD0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725101386; x=1725706186; 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=PLlRZBudcu0lYfVZFrWfCDmNfufwcjnWFsmygXQl1x4=; b=PcOxNIBSqLJEQJ/MPt/mBDfNy1g5cWdsCNd4fLXtyAcVFFkdUiSxQO+1g44fNLryHX k+KRoafPxffqje1//rtk3IXecGt9Vt8d92TQriqvVqUjYUAE2qMUGvvWUQooIuhvqGOh 3Prz3XautpwHwwSxjWl8Q7IHiJMguFDXOVKMHxTxN4u8ByNAbYFSXi+7iyvRnD7+bQXy aml21cko+inMmOE/JE89qeByjdJyTFl+IbCRr9kbsPBS2+Yzy55T/nRz6qsdn07pJrDw b20YNaa+nW35trus8BBbDHoOLkaytXjo4fBxSsp7MlERfaltQJayxEV1ryj56ksjzJLv SJAw== X-Forwarded-Encrypted: i=1; AJvYcCXuI2aS6YP/gZJ627IxdzhMTk1YQEXXRcZZCKVCwq0Wl+7ewNYlwQeUwrTZExDLyf85YEj31fYt5Q==@kvack.org X-Gm-Message-State: AOJu0YzaHLF8QLaewpOJ3hNymmdZEwZcwezfeI36zrRSwutMwf4p4Wrp fnyZEN4pMr/HE9BupDBuwTvsugyf9L0dbcz8w4I6DZuT1FDM4lQ7d96Fl4QuumyiwSWdcQYjtE4 8uZkETPfRe29OQkRhNWAJYpdzqz8H1iadlSo= X-Google-Smtp-Source: AGHT+IEbgi2v55hfNr0CeIbACWF0+0xRFrStO00QvCRxZUHHOS2FEhf1wvy5Xk+4HS1m94JXW/VS6KInFm7xT2jRt5A= X-Received: by 2002:a05:6102:6cd:b0:48f:3df9:ff9 with SMTP id ada2fe7eead31-49a5ae39a41mr10736962137.8.1725101385948; Sat, 31 Aug 2024 03:49:45 -0700 (PDT) MIME-Version: 1.0 References: <20240831092339.66085-1-21cnbao@gmail.com> <36933711-ae0f-468c-93bd-d6a67d974c9d@redhat.com> In-Reply-To: <36933711-ae0f-468c-93bd-d6a67d974c9d@redhat.com> From: Barry Song <21cnbao@gmail.com> Date: Sat, 31 Aug 2024 22:49:30 +1200 Message-ID: Subject: Re: [PATCH RFC] mm: entirely reuse the whole anon mTHP in do_wp_page To: David Hildenbrand Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Barry Song , Chuanhua Han , Baolin Wang , Ryan Roberts , Zi Yan , Chris Li , Kairui Song , Kalesh Singh , Suren Baghdasaryan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 3d4ahgpnjfx5tfmmbohtjoffkjihy4ru X-Rspam-User: X-Rspamd-Queue-Id: E09211C0004 X-Rspamd-Server: rspam02 X-HE-Tag: 1725101386-15956 X-HE-Meta: U2FsdGVkX18kW3cVniHLT2V4WU/KMSNVpICroDw4fxsZkvKJHDXtLpKHtv5mFX2XKnaktbLWaMgqpmsSueB1Y5IYRx5C5eK57LmFdGyadKswU716v8wXsJDaKwe3dVzjcC/srEQF2UFWvbwYkmTTeWyvJEYFoqZLLLo7SEfB40XjYmIgzjFQmW3njvDQ6kzewG/T4Bf+mD+9Un4PB47L1GD/DS4gW88O6yihsln+F3jM8haJYR7TfFuL6LXA/klqrtYdG0zQ+N1NYeF5uHeFBpk34xFeS3hXG3BH86PmXiH0xCoQxAR/f9ISPLrQFUBGk4rZNomINx7F46TgDdsy4kccCYXxOy3i7NMLUbNZ1dFVqvYzdG9et1FhiJ5ibrn1BDuw9+6BpfSxzJkE5BuEBcvOpRtxiKgjo8rxujmnEH1HO8raHwBvY1kfODfic6sbxi49/6HRgBLf/I0wKdLE/pXEc00qZof+Sn/zi2qAMVj8xEPjuEsuabmpL0JjmRFl5gVFKfLzct+LDM4hRK6M4gKqREhfAfmHSiVaG4A7/n1sR7KRuzbNovssOuqs+ocwHQQbPYHobAgIhmjOn/YrhQ2jK8L58J+gOufk/cQmL7xmvYtCASRWluyQjxkGGMEvwZP9QQqhf+XOnZ8YEpdur+7p7p7DLMvX0TKmJGjWaOT21TpUDXMZtkvIMMyFiq0Y/Z05hfFiM9PsbfEIsln+GM5gC30qeO+IVol2ZqYpXh45vjHe40FYq+6QqhzIzfBu4jkI6p+GyIriN39BGNwNzlEfi7PaSpQ1HmVkHjuaavmCKcDS3evIIh55ZHxa+uNO9JU3/ZdCCAMP7StAyh2WpJZGRkOEJzZt95xMwhu07ylRZIAF++68SWub7Q0XSRU32nv15o1D0SnFyCl4zqFBppQBWw4wJqqbXpNEGM+aettdnJAj/sOUHTEYMk4tED40wuwjeYrF6gaSLQl8coN yE+nw18y dc0kqApQy53zkhwA5AiGjWkXENIbgWXoGfJYJrQVuCkOXftfxZ1rtvXJh1c34nEVlE2ND+aZ7UoWwsk01notQ5EeIVR+7p0Eb1lsAv6WhppsF1AsZpE1M36NvGHH2CLps3a1GfFJtLYzLLuYEXga4MuMhHQr23K9EDcq83XueUyGS3e1JwXyxcdvfBD9MXkzHFqP2dWbGrDHh1UOEtWBqgBPO/WkwHPyDATfLDnCSAzaIHmmBlMzFV2d4A3HTIDR4cZNpCNW+PPyqua5O6wHvWYc4OeQ1slg5c6IHHzYuhQzi1lQGT1qlA60wAYjinjhd93C0os9x4SS8MpQ4OZfFjV/zYj2AKNJzjzDrGV0s4KFJz0mOO9F1f7psB2ygNs2hZOFHHabKO+GI0eWTHz34mKOzyLclnWCQ+4DTsXwPYeuTBEYtW9wQT65LUDxL3iftlYNm9DA4Ob1IxfHo4Vv6dEGe/ADIBXF82ib6VxdPgurpcoc= 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: List-Subscribe: List-Unsubscribe: On Sat, Aug 31, 2024 at 10:29=E2=80=AFPM David Hildenbrand wrote: > > On 31.08.24 12:21, Barry Song wrote: > > On Sat, Aug 31, 2024 at 10:07=E2=80=AFPM David Hildenbrand wrote: > >> > >> On 31.08.24 11:55, Barry Song wrote: > >>> On Sat, Aug 31, 2024 at 9:44=E2=80=AFPM David Hildenbrand wrote: > >>>> > >>>> On 31.08.24 11:23, Barry Song wrote: > >>>>> From: Barry Song > >>>>> > >>>>> On a physical phone, it's sometimes observed that deferred_split > >>>>> mTHPs account for over 15% of the total mTHPs. Profiling by Chuanhu= a > >>>>> indicates that the majority of these originate from the typical for= k > >>>>> scenario. > >>>>> When the child process either execs or exits, the parent process sh= ould > >>>>> ideally be able to reuse the entire mTHP. However, the current kern= el > >>>>> lacks this capability and instead places the mTHP into split_deferr= ed, > >>>>> performing a CoW (Copy-on-Write) on just a single subpage of the mT= HP. > >>>>> > >>>>> main() > >>>>> { > >>>>> #define SIZE 1024 * 1024UL > >>>>> void *p =3D malloc(SIZE); > >>>>> memset(p, 0x11, SIZE); > >>>>> if (fork() =3D=3D 0) > >>>>> exec(....); > >>>>> /* > >>>>> * this will trigger cow one subpage from > >>>>> * mTHP and put mTHP into split_deferred > >>>>> * list > >>>>> */ > >>>>> *(int *)(p + 10) =3D 10; > >>>>> printf("done\n"); > >>>>> while(1); > >>>>> } > >>>>> > >>>>> This leads to two significant issues: > >>>>> > >>>>> * Memory Waste: Before the mTHP is fully split by the shrinker, > >>>>> it wastes memory. In extreme cases, such as with a 64KB mTHP, > >>>>> the memory usage could be 64KB + 60KB until the last subpage > >>>>> is written, at which point the mTHP is freed. > >>>>> > >>>>> * Fragmentation and Performance Loss: It destroys large folios > >>>>> (negating the performance benefits of CONT-PTE) and fragments memor= y. > >>>>> > >>>>> To address this, we should aim to reuse the entire mTHP in such cas= es. > >>>>> > >>>>> Hi David, > >>>>> > >>>>> I=E2=80=99ve renamed wp_page_reuse() to wp_folio_reuse() and added = an > >>>>> entirely_reuse argument because I=E2=80=99m not sure if there are s= till cases > >>>>> where we reuse a subpage within an mTHP. For now, I=E2=80=99m setti= ng > >>>>> entirely_reuse to true only for the newly supported case, while all > >>>>> other cases still get false. Please let me know if this is incorrec= t=E2=80=94if > >>>>> we don=E2=80=99t reuse subpages at all, we could remove the argumen= t. > >>>> > >>>> See [1] I sent out this week, that is able to reuse even without > >>>> scanning page tables. If we find the the folio is exclusive we could= try > >>>> processing surrounding PTEs that map the same folio. > >>>> > >>>> [1] https://lkml.kernel.org/r/20240829165627.2256514-1-david@redhat.= com > >>> > >>> Great! It looks like I missed your patch again. Since you've implemen= ted this > >>> in a better way, I=E2=80=99d prefer to use your patchset. > >> > >> I wouldn't say better, just more universally. And while taking care of > >> properly sync'ing the mapcount vs. refcount :P > >> > >>> > >>> I=E2=80=99m curious about how you're handling ptep_set_access_flags_n= r() or similar > >>> things because I couldn=E2=80=99t find the related code in your patch= 10/17: > >>> > >>> [PATCH v1 10/17] mm: COW reuse support for PTE-mapped THP with CONFIG= _MM_ID > >>> > >>> Am I missing something? > >> > >> The idea is to keep individual write faults as fast as possible. So th= e > >> patch set keeps it simple and only reuses a single PTE at a time, > >> setting that one PAE and mapping it writable. > > > > I got your point, thanks! as anyway the mTHP has been exclusive, > > so the following nr-1 minor page faults will set their particular PTE > > to writable one by one. > > Yes, assuming you would get these page faults, and assuming you would > get them in the near future. > > > > >> > >> As the patch states, it might be reasonable to optimize some cases, > >> maybe also only on some architectures. For example to fault-around and > >> map the other ones writable as well. It might not always be desirable > >> though, especially not for larger folios. > > > > as anyway, the mTHP has been entirely exclusive, setting all PTEs > > directly to writable should help reduce nr - 1 minor page faults and > > ideally help reduce CONTPTE unfold and fold? > > Yes, doing that on CONTPTE granularity would very likely make sense. For > anything bigger than that, I am not sure. > > Assuming we have a 1M folio mapped by PTEs. Trying to fault-around in > aligned CONTPTE granularity likely makes sense. Bigger than that, I am > not convinced. > I see. maybe we can have something like: static bool pte_fault_around_estimate(int nr) { if (nr / arch_batched_ptes_nr() < 16) return true; return false; } if (pte_fault_around_estimate(folio_nr_pages(folio))) set all ptes; for arm64, arch_batched_ptes_nr() =3D=3D 16. for arch without cont-pte or similar things, arch_batched_ptes_nr() =3D=3D 1. Just some rough ideas; all the naming might be quite messy. at least, we won't lose the benefit of reduced TLB miss before all nr_pages are written for aarch64 :-) > > > > What is the downside to doing that? I also don't think mapping them > > all together will waste memory? > > No, it's all about increasing the latency of individual write faults. > i see, i assume it won't be worse than the current case where we have to allocate small folios and copy? and folio allocation can even further incur direct reclamation? > -- > Cheers, > > David / dhildenb > Thanks Barry