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 9E389C4345F for ; Thu, 18 Apr 2024 00:18:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1A74B6B0087; Wed, 17 Apr 2024 20:18:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 130766B0088; Wed, 17 Apr 2024 20:18:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01E2B6B0089; Wed, 17 Apr 2024 20:18:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id DA0D46B0087 for ; Wed, 17 Apr 2024 20:18:38 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8F2951A0992 for ; Thu, 18 Apr 2024 00:18:38 +0000 (UTC) X-FDA: 82020741516.15.FFBBF10 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf12.hostedemail.com (Postfix) with ESMTP id CEDD84000F for ; Thu, 18 Apr 2024 00:18:36 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CMOhhVmv; spf=pass (imf12.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=ioworker0@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=1713399517; 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=QZS7fC2PWWS/IdlGtc4NUsJMdrxWdm/lrLaZ1BKKIrA=; b=IYFk52Vwaj/VEhRsABWdSrZPYH8LeaJDOPQxhK6m9UZ33CobjprzeUZK7DgBMzcHeudtT6 VjSRNBM466vFsmeSXNanDjMdWAhKn0MKUIxckJrtVXuzH0gf18Olg9MNKjWOHh+mdDfqC+ Qw6BC+8EDOIG8u8kD1nXVY5J1RegGZY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713399517; a=rsa-sha256; cv=none; b=5UINCdwVp7mYiF7ZWq4ISxTPDyNPhNQCotSAdqD3fkrxxoXo3N9jzeyx0jMRr0e15yajoW VdmzixAUuFsUVkUmwvoyH6Zk1UiwHZupAIAyw1r6pM4lplrEn0oXGbk3yQdqJZVcTdttF3 rlS9H21fpAQ5Oypvz00RqF5DnzfKgeY= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=CMOhhVmv; spf=pass (imf12.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=ioworker0@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2d6ff0422a2so4277631fa.2 for ; Wed, 17 Apr 2024 17:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713399515; x=1714004315; 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=QZS7fC2PWWS/IdlGtc4NUsJMdrxWdm/lrLaZ1BKKIrA=; b=CMOhhVmvnGgURVa7UXZ7uKPZBxcJBoxa6M20yTpRgRZJsg589qQRRJf++LkIEbhiGo uU0duu3tYsH6CJwupcyscKjhPuJyOmjv4FjF1FeKaMEYOrPEV1YsE2hpUL9r219FVSLL 33Qn9UUSXCXBCNmYiO1viph6P1GkzchtcQ9GONiqwiDJwlvi54tRplf2gh5cELDh1Mp/ gD3RCcLZjAm2ChXI+kM2xTLjBkuQXQn9H4JezlKSVa13HCxZadceAvy+sX3qJiuqmkbW ga4ksO1qf11q4+Tb0MCUlXXtplhdFbacfnLBXUq6IsnPpOCVE8URycP3CdiiPLTBQY0l oDVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713399515; x=1714004315; 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=QZS7fC2PWWS/IdlGtc4NUsJMdrxWdm/lrLaZ1BKKIrA=; b=eH+Z6v9jD9e5hgx37DxODEKH31iNpKmfY/PuJHOAaAhvog7C+Iwo3J+3jb7NzRDq3O E7U5At6CmSl4yE+is2df07pBCstp2hwo9uG6bPBmUWiTVS6RShbMH5VHJplDZHyFkL1H 87OFxwXGs0UAC1XLUfTKyHvkr7v/VbruM/Mn86QsBKh6/AkGqR/9AQ7s9q5Vo8V73+y3 ugzmna7x5ePL9Q4rl6SfBxEciuaxwlFIoGwBuX1os3ZQsx6cyt2RDByC3R8exYLOYn3l 5mo9xK5G3kyYYc+kJZYXTxL82IQHyky/ygtdkAAiqqG8DQogct4IKh2yAN+mQVgjQQHZ YGYA== X-Forwarded-Encrypted: i=1; AJvYcCUDO5cm9tOYa78Cp3DZ1+R+eZ6veRATnA/GWz3C7xmvoDBR/HgRCnSzTkSXSTTJPVoxeJ80B/aWl1OBCbPZVFY1h0w= X-Gm-Message-State: AOJu0YyDGH/DZeq5FgSkghEwEosW7ggPFDd02XdphokE2YmbNkHdE+v9 J5dZoi8ePlHInorkzKMvxBsXcpwwPTx9vcTrSGHURnPgo++SEMC7rqdgRsjmmgf9dBDmatzuG1l OjIpOWO2gExqhVKfLQVxvG3lrwoc= X-Google-Smtp-Source: AGHT+IEBejyDNH6C17XdFAVAdzGc8hwPSw1HZ4W04ORI/5y4zasOKPQlH0VqgPA2yPvRtatffjk1hmQUf3drP2WpGKw= X-Received: by 2002:a2e:9f11:0:b0:2da:86c7:3b8a with SMTP id u17-20020a2e9f11000000b002da86c73b8amr372324ljk.43.1713399514736; Wed, 17 Apr 2024 17:18:34 -0700 (PDT) MIME-Version: 1.0 References: <20240417141436.77963-1-ioworker0@gmail.com> <20240417141436.77963-4-ioworker0@gmail.com> In-Reply-To: From: Lance Yang Date: Thu, 18 Apr 2024 08:18:23 +0800 Message-ID: Subject: Re: [PATCH v8 3/3] mm/madvise: optimize lazyfreeing with mTHP in madvise_free To: David Hildenbrand Cc: akpm@linux-foundation.org, ryan.roberts@arm.com, 21cnbao@gmail.com, mhocko@suse.com, fengwei.yin@intel.com, zokeefe@google.com, shy828301@gmail.com, xiehuan09@gmail.com, wangkefeng.wang@huawei.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-Server: rspam12 X-Rspamd-Queue-Id: CEDD84000F X-Rspam-User: X-Stat-Signature: 59prf3mtri4i9zziaiesau3rpt55rdjq X-HE-Tag: 1713399516-387877 X-HE-Meta: U2FsdGVkX1+3wkV8uyfy9lk+VB8pyBgqRsxhmKt62o58bmHEHA1qGTRGZhqP8UOrpcecx+EeOimnXcpAwLeF4cIK0BTd+aNe/cxmLk4wGPuaz6oW+4LPUB4fW0E9rDmIIY4pBM6LUxxXqznzMMaHYeBLqegj17rb7J1+xSz7Bh3UvCyVzaHzstPoPauXzJeS/rABWGUiKKNO4izdFENaicGi50xRD4ul7UCgFZVwmSxFxb+vz78Wl9C4X7NkXqUH5C2D1/04R/Kgh1f36L4yfBidzSqqZ3N1uwRq4FGmRC/SDHnMoSos72c6sf7/lHxf1l5+++oJMSLxTPtQfYc6TOeCWw58ycTOBtqeMkjTYiaL1wfxrm7H7U91WKxs/sqYY3F/aSiOQYETilzEuz0Qrak8u7P0PlXmbVLmc/9iuRUMKOxvNwF7jyHFYtt8BffUCu0TZnpe2xD9wtJa0zZaC0Q5xfFcqtQxTj0aZFRq7SLCfz1IyGHwYHLJHXsIp672mAswvrNGd7PtJJhjZ00gV+CRtLSalZeyt6t6Svtbj9RIc6rEcrLR0T9Q9JB1AyheoNkaOwQX1wUXi7++YaGLXbrrLQPLO4KlqaL/XFCvtmbJ7FLFk7TAPvtR26wm9XMVeRkNSf/Boocrj/WYqKFKRz95/4LRzLNo53xIUjBj1tMccYFjD+H+eQZwbgReJiIg38uZJXZbmKPk4goqCuKlid9X+iQd6Kg3qjudMjo2biVSH3PmC4AkNrLSPNusa/GLKjjpRDqvgiUjSyuF49AFYMwSlmVot5t91zOb1hI7Sp14A5VAv8E/v8kM4yyYAA8Sr4EnXm/RNFsmcrq6kaG7BwPa3ocJ6OSOdwRBmdRIPjan/KAEts05IJs5cRuJSk9q2MQGMwHh6YHXD5vWDbUn6WK62XhWZbs0jDtivYa2jIPEbjM0KFEYxu3J0U5Rf96jnZgtKquKTWu73c9pcaM U+VXFqkF +LHamSK9Dw7HPsnVeTWkNoRtWZH9xf+8iF2YGJuJptK36pL7TpcwbABeWT/kotzUNFw1h0Syb2hvieR1GU0hDujcGPg== 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: Hey David, Thanks a lot for taking time to review! On Thu, Apr 18, 2024 at 1:05=E2=80=AFAM David Hildenbrand wrote: > > On 17.04.24 16:14, Lance Yang wrote: > > This patch optimizes lazyfreeing with PTE-mapped mTHP[1] > > (Inspired by David Hildenbrand[2]). We aim to avoid unnecessary folio > > splitting if the large folio is fully mapped within the target range. > > > > If a large folio is locked or shared, or if we fail to split it, we jus= t > > leave it in place and advance to the next PTE in the range. But note th= at > > the behavior is changed; previously, any failure of this sort would cau= se > > the entire operation to give up. As large folios become more common, > > sticking to the old way could result in wasted opportunities. > > > > 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.590259 | 0% > > 16KiB | 2.990447 | 0.185655 | -94% > > 32KiB | 2.547831 | 0.104870 | -95% > > 64KiB | 2.457796 | 0.052812 | -97% > > 128KiB | 2.281034 | 0.032777 | -99% > > 256KiB | 2.230387 | 0.017496 | -99% > > 512KiB | 2.189106 | 0.010781 | -99% > > 1024KiB | 2.183949 | 0.007753 | -99% > > 2048KiB | 0.002799 | 0.002804 | 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@redh= at.com > > > > Signed-off-by: Lance Yang > > Some of the changes could have been moved into separate patches to ease > review ;) > > At least the folio_pte_batch() change and factoring out some stuff from > madvise_cold_or_pageout_pte_range(). But see below on the latter. Thanks for your suggestion! It makes sense to split some of the changes into separate patches for easier review :) > > > --- > > mm/internal.h | 12 ++++- > > mm/madvise.c | 141 ++++++++++++++++++++++++++++---------------------= - > > mm/memory.c | 4 +- > > 3 files changed, 91 insertions(+), 66 deletions(-) > > [...] > > > diff --git a/mm/madvise.c b/mm/madvise.c > > index f5e3699e7b54..d6f1889d6308 100644 > > --- a/mm/madvise.c > > +++ b/mm/madvise.c > > @@ -321,6 +321,39 @@ static inline bool can_do_file_pageout(struct vm_a= rea_struct *vma) > > file_permission(vma->vm_file, MAY_WRITE) =3D=3D 0; > > } > > > > +static inline int madvise_folio_pte_batch(unsigned long addr, unsigned= long end, > > + struct folio *folio, pte_t *pte= p, > > + pte_t pte, bool *any_young, > > + bool *any_dirty) > > +{ > > + int max_nr =3D (end - addr) / PAGE_SIZE; > > + const fpb_t fpb_flags =3D FPB_IGNORE_DIRTY | FPB_IGNORE_SOFT_DIRT= Y; > > Reverse Christmas tree looks nicer ;) Yep, I understand. > > > + > > + return folio_pte_batch(folio, addr, ptep, pte, max_nr, fpb_flags,= NULL, > > + any_young, any_dirty); > > +} > > + > > +static inline bool madvise_pte_split_folio(struct mm_struct *mm, pmd_t= *pmd, > > + unsigned long addr, > > + struct folio *folio, pte_t **p= te, > > + spinlock_t **ptl) > > +{ > > + int err; > > + > > + if (!folio_trylock(folio)) > > + return false; > > + > > + folio_get(folio); > > + pte_unmap_unlock(*pte, *ptl); > > + err =3D split_folio(folio); > > + folio_unlock(folio); > > + folio_put(folio); > > + > > + *pte =3D pte_offset_map_lock(mm, pmd, addr, ptl); > > Staring at this helper again, I am really not sure if we should have it. > Calling semantics are "special" and that pte_t **pte is just ... > "special" as well ;) > > Can we just leave that part as is, in the caller? That would also mean > less madvise_cold_or_pageout_pte_range() churn ... which i would welcome > as part of this patch. Yep, let's leave that part as it is in the caller :) > > [...] > > > @@ -741,19 +767,10 @@ static int madvise_free_pte_range(pmd_t *pmd, uns= igned long addr, > > } > > > > if (pte_young(ptent) || pte_dirty(ptent)) { > > - /* > > - * Some of architecture(ex, PPC) don't update TLB > > - * with set_pte_at and tlb_remove_tlb_entry so fo= r > > - * the portability, remap the pte with old|clean > > - * after pte clearing. > > - */ > > - ptent =3D ptep_get_and_clear_full(mm, addr, pte, > > - tlb->fullmm); > > - > > - ptent =3D pte_mkold(ptent); > > - ptent =3D pte_mkclean(ptent); > > - set_pte_at(mm, addr, pte, ptent); > > - tlb_remove_tlb_entry(tlb, pte, addr); > > + clear_young_dirty_ptes(vma, addr, pte, nr, > > + CYDP_CLEAR_YOUNG | > > + CYDP_CLEAR_DIRTY); > > That indent looks odd. I suggest simply having a local variable > > const cydp_t cydp_flags =3D CYDP_CLEAR_YOUNG | CYDP_CLEAR_DIRTY; > > and then use cydp_flags here that will make this easier to read. Nice. I'll use cydp_flags here in the next version. Thanks again for the review! Lance > > -- > Cheers, > > David / dhildenb >