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 244F0C48BF6 for ; Mon, 26 Feb 2024 13:01:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A8694440158; Mon, 26 Feb 2024 08:01:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A36CA440147; Mon, 26 Feb 2024 08:01:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8FE10440158; Mon, 26 Feb 2024 08:01:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7CA0B440147 for ; Mon, 26 Feb 2024 08:01:02 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 80F4FA01C4 for ; Mon, 26 Feb 2024 13:01:01 +0000 (UTC) X-FDA: 81833965122.04.C83C04D Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf07.hostedemail.com (Postfix) with ESMTP id 6066B40035 for ; Mon, 26 Feb 2024 13:00:59 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf07.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708952459; 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; bh=uYbOipUIXWA12sEusDXTNpO2BUCqZFbo215FMxXTIq8=; b=m1M/Xcl+dfe4AFAf0NTHB/+SBI/Rqe2PuJn0pHS9CxrS7k9z1LVMHc29fiVNYWwWvoajTW XO6GBrfTZB4NJo8EivWwtwDoJeAOseHTz6xHESfLGXcVuTxOvOiHHaNIbFJVAdXGy0b93O GTs2XC2BALfNZdkji0ihieEKOj21oCQ= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf07.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708952459; a=rsa-sha256; cv=none; b=0IQ9Z5KdiXnnxeQldoXveBl3+74VPA8F2ElEF/2O1kz5HCxL5ujxai/jdU89VwGqnc0YT1 MfquNrKl0hEy1cBo/NmWX7kx5lsN7WzJE4RXC1Af1KM6kD47UNIMb5ws0LKd0mkUYnRoZS 4v/AftHhtCozDecThSxPmNRCJBbzi6Q= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 2A033DA7; Mon, 26 Feb 2024 05:01:37 -0800 (PST) Received: from [10.57.67.4] (unknown [10.57.67.4]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8574B3F762; Mon, 26 Feb 2024 05:00:56 -0800 (PST) Message-ID: Date: Mon, 26 Feb 2024 13:00:54 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/1] mm/madvise: enhance lazyfreeing with mTHP in madvise_free Content-Language: en-GB To: Lance Yang , akpm@linux-foundation.org Cc: zokeefe@google.com, shy828301@gmail.com, david@redhat.com, mhocko@suse.com, wangkefeng.wang@huawei.com, songmuchun@bytedance.com, peterx@redhat.com, minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240225123215.86503-1-ioworker0@gmail.com> From: Ryan Roberts In-Reply-To: <20240225123215.86503-1-ioworker0@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 6066B40035 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: hnu37cmh73qw87s5gfz8fync9b3rc5an X-HE-Tag: 1708952459-790864 X-HE-Meta: U2FsdGVkX1/7gNtzqXYJAOaPHI60eAqtRLpGTAY5lmOJt7mbZmM9Da7rKlf0jeCQ+uEzV7UpDI4DTFzC0BGGPUDtYy3glRthvOeN/8kyUMg9SDwFtY1kaX6qBk6HhWv2hWZgQk6LkegyoFagZlhRMThdzG/4Uy/LVqvSckWa/AgK74nQwZB1iY38eJ+emiPoGuhw9lCWAiSVJP/HoEwPPMUnUoUfY7vdR0tpBd5K/fBoBhUtIPhFgo2fpskTacVJIZ2O0B7IyEFM1CncBHiGcBnH5vb6UcFNCTnHvL2Cg2LTHTzAzR5WNz40GYK4I+iZxb+N2OfSHbWazWthR9FqFEU4zrW2GS/PpzP5+47ezYnTVHLPjhpF/I79xBJfVKXE0Mr8cZpDWtMdh8NK7B18SRxEFYoX507l1raWK05gzTzif1FIMKompBkjDZm1FeiPGXNR7iJcDqJyZZn6EA9racPszY6gkLP4hHqPdFpLcG2vP1WVaqfDDXiVQldzPUS0lz/IR6FoS4jOJd+Z2ZUDnXgGhmEc6xgRPP5ezW1eEKxrWPkfQbgrmzPBI1fmi/BQ6QbpQytdG+9meSm3a7vLGqomIR+qYYayzggEw82ZdqAWlOnxTc3E/Gsajqjdj5008b46g+qyTfpQURP16wzshzBsiwS/st4q4DXRu7BExRRa8DMmbXDx1i5olZigw7WCJE3Jq3mnbJdEx98bm94h3xfHpWs8T7nSoavG18bBXpavNm9WezceuaDLhM6vqLnb1aVTYoh5ezyIWqsMvu/G2I/THHCwgUvU8f5hl2+kximMwGuqSltHoEEchTIzC5LR+m3Zya0keyT2Mi4/MkGgQhZRLy1DTYr6kVg/TF14B3vlWw16tGcKyH2lUJIhhgkwJFLHpnjhM4I7gM9F+Njmx5BCLSBOqkmz+aaETT1VzGhuQj4vgcHpcqxbRG9c6WWmZDTYMpxFb3NotIBZfHO 5B0MCSw2 kx/EGgHCRDHujFQrrMF4A/jJrcq3tQybqGoFBaMV9+vI7BXgkAZ4sHnE0ApPPdtxA4StbW1oWIeYwfLOGbz2xxQPza/SC3VR2Zml9Li/Xzx4lTM9/yK0QePzOe0Op+gMXFk8/R24PLl5QvqtV8u6i8W/0GR/3z4zwPj9N4xrxdcu3Yqgi6iDSlm+rtxcMq7OSSweEj0dtgAkJ9RSygHybe8TYbueVCD/WRTykBGq89yc4J5VFtwjC3N1R1gjTuvytWjp/J/M1shxYH6hKGx6zwncQVZ9H7Ts7Y2yX8kJ/aztFABJMXWiHErTwssoqr6AV4JAOy2EMLKGZKu5Vmarrblpb8WeEwIuSVlQb8nj9cIjO7iLp5jtUbQbpZInkJl0rn4dM 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: Hi Lance, Thanks for working on this! On 25/02/2024 12:32, Lance Yang wrote: > This patch improves madvise_free_pte_range() to correctly > handle large folio that is smaller than PMD-size When you say "correctly handle" are you implying there is a bug with the current implementation or are you just saying you can optimize this to improve performance? I'm not convinced there is a bug, but I agree there is certainly room for performance improvement. Thanks, Ryan > (for example, 16KiB to 1024KiB[1]). It’s probably part of > the preparation to support anonymous multi-size THP. > > Additionally, when the consecutive PTEs are mapped to > consecutive pages of the same large folio (mTHP), if the > folio is locked before madvise(MADV_FREE) or cannot be > split, then all subsequent PTEs within the same PMD will > be skipped. However, they should have been MADV_FREEed. > > Moreover, this patch also optimizes lazyfreeing with > PTE-mapped mTHP (Inspired by David Hildenbrand[2]). We > aim to avoid unnecessary folio splitting if the large > folio is entirely within the given range. > > On an Intel I5 CPU, lazyfreeing a 1GiB VMA backed by > PTE-mapped folios of the same size results in the following > runtimes for madvise(MADV_FREE) in seconds (shorter is better): > > Folio Size | Old | New | Change > ---------------------------------------------- > 4KiB | 0.590251 | 0.590264 | 0% > 16KiB | 2.990447 | 0.182167 | -94% > 32KiB | 2.547831 | 0.101622 | -96% > 64KiB | 2.457796 | 0.049726 | -98% > 128KiB | 2.281034 | 0.030109 | -99% > 256KiB | 2.230387 | 0.015838 | -99% > 512KiB | 2.189106 | 0.009149 | -99% > 1024KiB | 2.183949 | 0.006620 | -99% > 2048KiB | 0.002799 | 0.002795 | 0% > > [1] https://lkml.kernel.org/r/20231207161211.2374093-5-ryan.roberts@arm.com > [2] https://lore.kernel.org/linux-mm/20240214204435.167852-1-david@redhat.com/ > > Signed-off-by: Lance Yang > --- > mm/madvise.c | 69 +++++++++++++++++++++++++++++++++++++++++++--------- > 1 file changed, 58 insertions(+), 11 deletions(-) > > diff --git a/mm/madvise.c b/mm/madvise.c > index cfa5e7288261..bcbf56595a2e 100644 > --- a/mm/madvise.c > +++ b/mm/madvise.c > @@ -676,11 +676,43 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr, > */ > if (folio_test_large(folio)) { > int err; > + unsigned long next_addr, align; > > - if (folio_estimated_sharers(folio) != 1) > - break; > - if (!folio_trylock(folio)) > - break; > + if (folio_estimated_sharers(folio) != 1 || > + !folio_trylock(folio)) > + goto skip_large_folio; > + > + align = folio_nr_pages(folio) * PAGE_SIZE; > + next_addr = ALIGN_DOWN(addr + align, align); > + > + /* > + * If we mark only the subpages as lazyfree, > + * split the large folio. > + */ > + if (next_addr > end || next_addr - addr != align) > + goto split_large_folio; > + > + /* > + * Avoid unnecessary folio splitting if the large > + * folio is entirely within the given range. > + */ > + folio_test_clear_dirty(folio); > + folio_unlock(folio); > + for (; addr != next_addr; pte++, addr += PAGE_SIZE) { > + ptent = ptep_get(pte); > + if (pte_young(ptent) || pte_dirty(ptent)) { > + ptent = ptep_get_and_clear_full( > + mm, addr, pte, tlb->fullmm); > + ptent = pte_mkold(ptent); > + ptent = pte_mkclean(ptent); > + set_pte_at(mm, addr, pte, ptent); > + tlb_remove_tlb_entry(tlb, pte, addr); > + } > + } > + folio_mark_lazyfree(folio); > + goto next_folio; > + > +split_large_folio: > folio_get(folio); > arch_leave_lazy_mmu_mode(); > pte_unmap_unlock(start_pte, ptl); > @@ -688,13 +720,28 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr, > err = split_folio(folio); > folio_unlock(folio); > folio_put(folio); > - if (err) > - break; > - start_pte = pte = > - pte_offset_map_lock(mm, pmd, addr, &ptl); > - if (!start_pte) > - break; > - arch_enter_lazy_mmu_mode(); > + > + /* > + * If the large folio is locked before madvise(MADV_FREE) > + * or cannot be split, we just skip it. > + */ > + if (err) { > +skip_large_folio: > + if (next_addr >= end) > + break; > + pte += (next_addr - addr) / PAGE_SIZE; > + addr = next_addr; > + } > + > + if (!start_pte) { > + start_pte = pte = pte_offset_map_lock( > + mm, pmd, addr, &ptl); > + if (!start_pte) > + break; > + arch_enter_lazy_mmu_mode(); > + } > + > +next_folio: > pte--; > addr -= PAGE_SIZE; > continue;