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 C5C0FC369DC for ; Thu, 1 May 2025 22:54:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3841A6B0088; Thu, 1 May 2025 18:54:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 332CA6B0089; Thu, 1 May 2025 18:54:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1AE5D6B008A; Thu, 1 May 2025 18:54:05 -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 E463B6B0088 for ; Thu, 1 May 2025 18:54:04 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 89261141663 for ; Thu, 1 May 2025 22:54:05 +0000 (UTC) X-FDA: 83395843650.14.BDDF26F Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf14.hostedemail.com (Postfix) with ESMTP id 3A23E100007 for ; Thu, 1 May 2025 22:54:03 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Rzr9WJ31; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf14.hostedemail.com: domain of npache@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=npache@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746140043; a=rsa-sha256; cv=none; b=uWj9LzkVFejRCkFEjN0uZbR4hnuevSdf3QxJjxlEOyybqyVjSLk38I7AbcdumFWnvgmnmm QyxvM3PIygRXKjeMzaCgRHeqhEfE7ptEflMOJOOtwjB8O7Cm3WZOtGX+VzAtED5fjmLTLe BGvPQKo9QNHeji61CE5V5UrjvI0JlIw= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Rzr9WJ31; dmarc=pass (policy=quarantine) header.from=redhat.com; spf=pass (imf14.hostedemail.com: domain of npache@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=npache@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746140043; 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=KtLg0B1vrzZBeuo/C7fy1HGxDtxIeRaGRM5T8fcaxh0=; b=0fp6LKcHtzrusV/6NioiTcVzcB88E0e6v19Qxy3c/EoPGKqBB9Ukkg++cp6/b4gVSMMQKs QxogI1a3cWSobp1gWiQQ4W1zZfzyYA05Brv+e51DkhkYGEss5UwjhLXFfnGMqVMUlaN4of ObpEa10u+BRX8h8A4Ju3Vbq2JSsoJkg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1746140042; h=from:from: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=KtLg0B1vrzZBeuo/C7fy1HGxDtxIeRaGRM5T8fcaxh0=; b=Rzr9WJ31vCRyHJCBM9qqcQM3QQui2ALwJSkGfjuo7N6g5l+SZ8ZMr+LDwejWoD0TZrL1FF G3Q2vUzExePy0TvBt6PIVSzHlkCmeixiTze4B1vdpcxA0nEJGZXk1UWoXm5rBuv22EJqQL GKMOOsj5RM9Su03HrX9hkmilip+iYVw= Received: from mail-yw1-f200.google.com (mail-yw1-f200.google.com [209.85.128.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-591-I3o4sPxMPxyIpymqK2rFiA-1; Thu, 01 May 2025 18:54:01 -0400 X-MC-Unique: I3o4sPxMPxyIpymqK2rFiA-1 X-Mimecast-MFC-AGG-ID: I3o4sPxMPxyIpymqK2rFiA_1746140041 Received: by mail-yw1-f200.google.com with SMTP id 00721157ae682-708af1dc9easo20492567b3.2 for ; Thu, 01 May 2025 15:54:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746140041; x=1746744841; 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=KtLg0B1vrzZBeuo/C7fy1HGxDtxIeRaGRM5T8fcaxh0=; b=U4WfomMl4W1kiqmy5YE0QBT3ugaKw+W7LTF2QMg3Sq9+zf+5+55n33GUCus2fFhIM+ 7Efx2mDYp8iKwvc7jOhRnLD7McgPT0RLSMI2baec5zwN1thvH6TugCOIFeqMu6ELHa9b Ib27MzLsqczJIzhYhCV1raa9pN+2DS/tWMX3f7++5oLmzwGp+iTOjHtYVS0jfsfnjEe9 sd0pFDHk6vKl9t6MpIVJN2D8nkqxBHNALzFkgho9UwcxQHQH7FvelCFv3VjcmsLbbSy2 Gt5QNgZkvsxPWoFn9mz8TquFa+WdAJUHklnXg6C78udcWQukUayEXTf6TDhCf2vq5eNF 52Qg== X-Gm-Message-State: AOJu0YyDIDLL0h6Dq+vxURciGu4wELjd2557NnOFH9lCYXroOTFAzlqL 7NaULUl2lMfcLbHsFHMZJ62n+GXOQK7fRZeY+2gNx6yCnYz3GdXHLNjVMmsBOnZZv5obh5VVDLw tEL70F4lBDHZ6o+frMptyqOKoJIW6/vtS6OdpZCn/36AAi1I+ckl0Rvk5cxMnjSA/DOSuncPukF pcCkBjCmc5UlULbaBEx50JHsc= X-Gm-Gg: ASbGncs2coSGUPLzvNVQ2O96nnLjb9jR2c+Bj45jPEI5E8m/NGaD+AgoDYVWcgP4E+u bZAMVcuWlilMkIKQNW5CsELwF2s76posU58k+rNogRnhS+nUJAQo9T9LCd+ULbahlohwYH5CkqY a5Kgy4gYc= X-Received: by 2002:a05:690c:6892:b0:708:15dd:712 with SMTP id 00721157ae682-708cee0d4e0mr15576467b3.32.1746140040870; Thu, 01 May 2025 15:54:00 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGGPElw1UZQRMg/NB24PlPPnaQvolOetsYL1qWqN2H/DAHnfrkNvMouRvuxZDqL6cOU1L++ooR/hLBGonde+Go= X-Received: by 2002:a05:690c:6892:b0:708:15dd:712 with SMTP id 00721157ae682-708cee0d4e0mr15576337b3.32.1746140040523; Thu, 01 May 2025 15:54:00 -0700 (PDT) MIME-Version: 1.0 References: <20250428182904.93989-1-npache@redhat.com> <20250428182904.93989-4-npache@redhat.com> In-Reply-To: From: Nico Pache Date: Thu, 1 May 2025 16:53:34 -0600 X-Gm-Features: ATxdqUG3EUSAuZQcIBHamAtOStWW2NfUYwlhaLO5OYc6mM0jjaysT4fqAsR4EYU Message-ID: Subject: Re: [PATCH v5 3/4] khugepaged: add defer option to mTHP options To: Zi Yan Cc: linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, akpm@linux-foundation.org, corbet@lwn.net, rostedt@goodmis.org, mhiramat@kernel.org, mathieu.desnoyers@efficios.com, david@redhat.com, baohua@kernel.org, baolin.wang@linux.alibaba.com, ryan.roberts@arm.com, willy@infradead.org, peterx@redhat.com, shuah@kernel.org, wangkefeng.wang@huawei.com, usamaarif642@gmail.com, sunnanyong@huawei.com, vishal.moola@gmail.com, thomas.hellstrom@linux.intel.com, yang@os.amperecomputing.com, kirill.shutemov@linux.intel.com, aarcange@redhat.com, raquini@redhat.com, dev.jain@arm.com, anshuman.khandual@arm.com, catalin.marinas@arm.com, tiwai@suse.de, will@kernel.org, dave.hansen@linux.intel.com, jack@suse.cz, cl@gentwo.org, jglisse@google.com, surenb@google.com, zokeefe@google.com, Liam.Howlett@oracle.com, lorenzo.stoakes@oracle.com, hannes@cmpxchg.org, rientjes@google.com, mhocko@suse.com, rdunlap@infradead.org X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: iA9oga7E4xO_zqOPhH35M1XNo2cWO7-OHTH45BcaAt0_1746140041 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 3A23E100007 X-Stat-Signature: 18j1ot6epuki7efd5uukhh8oo18yraim X-Rspam-User: X-HE-Tag: 1746140043-45695 X-HE-Meta: U2FsdGVkX19pGc5X29UTOAOPblY3BD+gsqYlpEgShiA8Sub+Qnnz0yNlr5+OiTwF1uBmDVepPxFBvHTD0Vzgml1ZGQ+tu3YGwzOhf1VGGkgFdNQs86pkoVKFThyNxebmmN8INPOQNehxoY7F8BeUqboU3G9ux0ljor/uhI+kmw2ZGCc/3vhs9b1Yi5y6A5fniMtuUC1UYcarC4uBaRt2t24qlRmSwJrNfPdXyLbpRTn14fgCi9bv2SDRme3cVNfU7bZlqZTZQPHDIh+HR9UrUwmvLfIQTsfFc6u1ZF+3Sbbyl8GdcRRX2iTZrlyz1hWgwJo5BBpPZr0EIurdHSAQIm+JTn6He0UrywlzpfKqspysKQuMB8sOwQj9vmpY6itxguENJBBzyatCDBqv6vu67R4tAGF1QJzmZRhqgpo6EQ5mtkX+UbX/tANyQTZ5cbKOWDJ1AjSU1rYe/0SEm/lbet9pYu5y02CUd2j5bl2dYqPb+NlkhcPRrQSZhzU8Rn3RmbPM5YcXAehnivaSHIk2EdfC3PVE/QNsyAB8tb5RZg4Mktd6mI4D9yCQGbkKdaVnNAQl6a1cfLncj51fnB+5eoXzpPS+8zznbgXKRGX2DUnVaBN8K138/rtKjCqqSHU/LE4BZPVfTFzZBiRclHIdB9PxteaRy7mW2AM/WKy6ntB+pj2LK0mLDQ6LYCdUDQu95nqvJ2FTiFLKoHSE3jqRbCLs71gS2vL+/f6P4Y6NOVHi33xfKusKNP52/cntoNwYO8U/daTFoV0NgJK4bOF8hppYkHQ4YfsnJdAS3v7RC1StHurAscpZsferOydeRmDax+egbfadar/bQ5qjQdSb10+deNEklfG5cKubDAv0wTsGwBVg85hFJ8PW+lpozj7+wl653c688dDR2o4JTtrVCTRSb914U6+2hkZjJCh5an54O49jVHx2UA648PqD4nnUPCW8gxJpOFpBEuqBBU0 729AKQu9 Bg0M6CLGQUfuiEYpGoGvoqYEylMHdkYx5AoMOAOBN3HpG7M0EzJZPj2b7S6yDvlG1kMRy33gO0lQMmFHehu8WL28FLKKTL0NuaGeVZDkgzQYhFtZFdCdb/vMiZu5O6xtEpWMN0nNsfx8dZyG3J+EDM4tJYCFjuW1wQyNaKYwa0ElsBW1UchInnqfyYjMAu2mK+S6cmhJuFN+C4XKncnxtupG5c9qFlalc6sr2oFgv+m9yiZ/YL3shU4R5HqKsgaMQLc5zTc7DmNXHlHdu5BetwK+Oi4iO/qBed8f7/cmIxkLyvdwYuFG1MoiAD4L+fo/8c2rqfoi9bVGnC6q0Y7R5EJfQfd5Gl3n+NjIRhs3qpuY7T433fjmijeW8OA== 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 Wed, Apr 30, 2025 at 2:34=E2=80=AFPM Zi Yan wrote: > > On 28 Apr 2025, at 14:29, Nico Pache wrote: > > > Now that we have defer to globally disable THPs at fault time, lets add > > a defer setting to the mTHP options. This will allow khugepaged to > > operate at that order, while avoiding it at PF time. > > > > Signed-off-by: Nico Pache > > --- > > include/linux/huge_mm.h | 5 +++++ > > mm/huge_memory.c | 38 +++++++++++++++++++++++++++++++++----- > > mm/khugepaged.c | 8 ++++---- > > 3 files changed, 42 insertions(+), 9 deletions(-) > > > > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > > index 57e6c962afb1..a877c59bea67 100644 > > --- a/include/linux/huge_mm.h > > +++ b/include/linux/huge_mm.h > > @@ -96,6 +96,7 @@ extern struct kobj_attribute thpsize_shmem_enabled_at= tr; > > #define TVA_SMAPS (1 << 0) /* Will be used for procf= s */ > > #define TVA_IN_PF (1 << 1) /* Page fault handler */ > > #define TVA_ENFORCE_SYSFS (1 << 2) /* Obey sysfs configurati= on */ > > +#define TVA_IN_KHUGEPAGE ((1 << 2) | (1 << 3)) /* Khugepaged defer= support */ > > Why is TVA_IN_KHUGEPAGE a superset of TVA_ENFORCE_SYSFS? Because khugepag= ed > also obeys sysfs configuration? Correct! The need for a TVA_IN_KHUGEPAGED is to isolate the "deferred" mTHPs from being "allowed" unless we are in khugepaged. > > I wonder if explicitly coding the behavior is better. For example, > in __thp_vma_allowable_orders(), enforce_sysfs =3D tva_flags & (TVA_ENFOR= CE_SYSFS | TVA_IN_KHUGEPAGE). I'm rather indifferent about either approach. If you (or any others) have a strong preference for an explicit (none-supersetted) TVA flag I can make the change. > > > > > #define thp_vma_allowable_order(vma, vm_flags, tva_flags, order) \ > > (!!thp_vma_allowable_orders(vma, vm_flags, tva_flags, BIT(order))= ) > > @@ -182,6 +183,7 @@ extern unsigned long transparent_hugepage_flags; > > extern unsigned long huge_anon_orders_always; > > extern unsigned long huge_anon_orders_madvise; > > extern unsigned long huge_anon_orders_inherit; > > +extern unsigned long huge_anon_orders_defer; > > > > static inline bool hugepage_global_enabled(void) > > { > > @@ -306,6 +308,9 @@ unsigned long thp_vma_allowable_orders(struct vm_ar= ea_struct *vma, > > /* Optimization to check if required orders are enabled early. */ > > if ((tva_flags & TVA_ENFORCE_SYSFS) && vma_is_anonymous(vma)) { > > And code here becomes tva_flags & (TVA_ENFORCE_SYSFS | TVA_IN_KHUGEPAGE). or just (enforce_sysfs & vma_is_anon) like you mentioned. Then we check for the TVA_IN_KHUGEPAGED before appending the defer bits. > > Otherwise, LGTM. Reviewed-by: Zi Yan Thanks ! > > -- > Best Regards, > Yan, Zi >