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 7CBEEC54E5D for ; Tue, 12 Mar 2024 13:56:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC61E8D0049; Tue, 12 Mar 2024 09:56:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E75E88D0017; Tue, 12 Mar 2024 09:56:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D3D1F8D0049; Tue, 12 Mar 2024 09:56:09 -0400 (EDT) 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 BF8D58D0017 for ; Tue, 12 Mar 2024 09:56:09 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 8D6621A09A0 for ; Tue, 12 Mar 2024 13:56:09 +0000 (UTC) X-FDA: 81888536058.03.8F3FC58 Received: from mail-yw1-f174.google.com (mail-yw1-f174.google.com [209.85.128.174]) by imf20.hostedemail.com (Postfix) with ESMTP id E36F31C000D for ; Tue, 12 Mar 2024 13:56:07 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LD5ImSA2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.128.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=1710251767; 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=2ObhHYkbotn3YeHlHYrYqfV8bb8V+riZ34qdc2tMCTU=; b=q+PBKTgAhxwdvv+P+naylPtV3uu4zmGmb9hIrbyeMQQVl1+BTC2vJnMwYwhOry5IWDNHSH vMTpLeQSZwRLFSahjVugQ/6WYBI609gELoKJAcdMjM3UQ750YyvIRpCnNr4n9cTOiuifP8 AWnekybmAJAMZML2DzTolodOvyuP8zw= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=LD5ImSA2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf20.hostedemail.com: domain of ioworker0@gmail.com designates 209.85.128.174 as permitted sender) smtp.mailfrom=ioworker0@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710251767; a=rsa-sha256; cv=none; b=ipkWQng1Df0LYEqf97kDqM6ZZ3E90XnY/7c2DoDWZ4idpF4OlvJUdQisPeqh1UiNaR+9aW sehB1Ym/aOkP27h0zXSe+sDylyJojYbnskDscfo7Mc3SHpAQdHS4cB7FjBlrjyR/06uXDK XN5ElOlwM2pJeORbZtWxnQPeBSOqfFY= Received: by mail-yw1-f174.google.com with SMTP id 00721157ae682-60a434ea806so19946307b3.3 for ; Tue, 12 Mar 2024 06:56:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1710251767; x=1710856567; 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=2ObhHYkbotn3YeHlHYrYqfV8bb8V+riZ34qdc2tMCTU=; b=LD5ImSA2Nz2Y76l8HCJumq7LDJSNdcQa/qLfngCMYeO6MZiHD1a0GlaIdweR3q452Z IPVd5prffqmuKtucYQkV9emnYSNnBh+UoJTCrnKQ46iJSdt4OOtURXEeHXt+pZpjucYI oi6TEgjoi8GtupYhBjM8+1UlXO/AiZXpkRTqO8wjL6oB1Lds1+c54AovX2AiKRmBRRhs d75UEquy/RH4ZQaZ6GKsxcwrUnPvhcYxod7bw7gpYIHeFYyGLYUKUedwEf/roprA7r4a nyOu3BXNMc5GdkToPUeDAcxxNOzKJ+dmErcbYyjRGT7Wgf4syD8t/ceuwgvLO9obA1zE DXcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710251767; x=1710856567; 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=2ObhHYkbotn3YeHlHYrYqfV8bb8V+riZ34qdc2tMCTU=; b=kRY/FJLJb+HARz/RFhyHC0422ypMsY8b351Eg/+581fBS1+jE5CFG3TTUs/myv7CTG AnQgjrDQ3TPkuxmVUunIHYSvyiEBxWHCmLVDXXSvxK2aJbouVSDXC0BMPk5Z5HmmA4T4 ONEkVrFaQpwoH5koI1ISVIHDEZKoAeYidu2yzFbMa9v/PR1mcEiE6at/t16rrnHCNMDd YuDjJgYl2EFMcIMbUJPsAM0mW/sumi6kEQywR//exA3PX0cHJoE2AgFVLmt2kJpzwemS vwpqB5vZ1dhHFIrDJ+4ycEfdHY7kE/XBulYH4jKF6TfkGTQl6SBWq9EjZYH0A3iYojkx 6IFA== X-Forwarded-Encrypted: i=1; AJvYcCUsCX7s8iBy7CQwIbHV7GM+s8sF2WjCKSPZkpMxuXUd8yBgVXdXgkfVAMpCG5eYoE6RMLTblI1yI5xfG/7K7KSW46E= X-Gm-Message-State: AOJu0YzJmnoZmWJQahnVbURWcHXTyBhyY4n2gHZNJ5le6pWPG82w1Krm pfOX2qGfQh+ykp+LTC99izKjsXqUVwyybGLPXmoRW1jYCijE4f9011FuI81q1yRL3SVryviGgit S+WCL5QJRrxcJpZ3pKNkzFvhoUuP+75vs47PVP+Hc X-Google-Smtp-Source: AGHT+IGzv+lKZEO35O6m8MkRNlv5HcmXLRTaaRXheWwJB1SR0QtsrhzIbMOmTmygNjfXHEASLfuerLzpKHUgaDPLQkM= X-Received: by 2002:a0d:d94d:0:b0:60a:16b8:103f with SMTP id b74-20020a0dd94d000000b0060a16b8103fmr287298ywe.45.1710251766915; Tue, 12 Mar 2024 06:56:06 -0700 (PDT) MIME-Version: 1.0 References: <20240308074921.45752-1-ioworker0@gmail.com> <75630ba6-79b6-4105-b614-29cfb0331084@redhat.com> In-Reply-To: <75630ba6-79b6-4105-b614-29cfb0331084@redhat.com> From: Lance Yang Date: Tue, 12 Mar 2024 21:55:55 +0800 Message-ID: Subject: Re: [PATCH 1/1] mm/khugepaged: reduce process visible downtime by pre-zeroing hugepage To: David Hildenbrand Cc: akpm@linux-foundation.org, mhocko@suse.com, zokeefe@google.com, shy828301@gmail.com, xiehuan09@gmail.com, songmuchun@bytedance.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: E36F31C000D X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: nzr7cutntkzz7fq1k9b5c7f4h5ur4n5n X-HE-Tag: 1710251767-340389 X-HE-Meta: U2FsdGVkX1/rTI+hUKkZ4OkHdAG8ktche/CpWfWzkG67+6zMRPPmooVoGoe6SwXumXdYblPoR1xPLHkPVcrai4HsYWNsO7fjmjc+ZBujdqxSFbcHuVsjGNJiPu6VqZjSv0uLFN979zBe54DI9EgKw8fbFRx6kzlAYiEthLQPiBjV1RRgqy//cxqDVkPhXtS1S3HkdtVsum/jkxtuF8/rx5G1bQSzKvFawbFcO9suBG9fW//eOlwlu+2aKyMBvmCLZP32ihJVrKcvlldVO4cuwaHbgLvCIt+AP0iKpHUUDlV0E+YWYBHJDyVL8eBg7JgDdOMcwMl96u+R8MbXRWFzeWB3pUbbkSVsyjSMVDyLZ+p+HYHB1V+F/iMaNMA9d827PowyytuXKB3RuC9P2DEph4SQHTSmkpNuSZ1whvm6fTZW/0nbgF07m/gjRt+ow4BPsaiiUL5wAN0f6LH6FOO5C02I98IhVDqMJBpLMGZEF2iv/U/wxqlg7NqyHDY3gBzswN2ScD32si0YNDU7cPkf9TLx7keaT085oh9LTT5Mxb0B2r6zNbjUdOpBbMRZHOQ0f75I9S2HPwTYmzVvppx08i4Yq1sqnSde3tS4dfeeTxf3FMNBRdCLsk3B8Eg8NdClQ74x2MHgxmw0Hu9L5msGaQzfhqJFFrIWAkbFsf/xVRGfAOAXR9C+NGA6G6AnBOGBdMgeQI/bMwgf9Hcgzt9TKzjcDVshVBuww2rDvqea5y2s1yPxQGbujxhuoglPw7VaOcIpfFz7hTRtJ1hs3PgxhoHPZn3TXGqKthHAXPCGLKiGhiC6VoGG2NtJa1hz9MZIgZHC7Zwaq4DGgl0pUayvV+7hDDNbDTuoweLcV8CJcuuHnS4eDIQheqoQAqruGwt7DBMVnPyUYBpfXaYU/wwbYbr3hutzToddT7Cms5o7U3aUA1lL09J6Z5qjy5a4lP8KcfPpbHQBH7dhhJTKkq0 4+GT20rV vzYXbqv5oftrZFHKRgtoh9iY/14dn1Vcyjdoj 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 Tue, Mar 12, 2024 at 9:19=E2=80=AFPM David Hildenbrand wrote: > > On 12.03.24 14:09, Lance Yang wrote: > > Hey David, > > > > Thanks for taking time to review! > > > > On Tue, Mar 12, 2024 at 12:19=E2=80=AFAM David Hildenbrand wrote: > >> > >> On 08.03.24 08:49, Lance Yang wrote: > >>> The patch reduces the process visible downtime during hugepage > >>> collapse. This is achieved by pre-zeroing the hugepage before > >>> acquiring mmap_lock(write mode) if nr_pte_none >=3D 256, without > >>> affecting the efficiency of khugepaged. > >>> > >>> On an Intel Core i5 CPU, the process visible downtime during > >>> hugepage collapse is as follows: > >>> > >>> | nr_ptes_none | w/o __GFP_ZERO | w/ __GFP_ZERO | Change | > >>> --------------------------------------------------=E2=80=94---------- > >>> | 511 | 233us | 95us | -59.21%| > >>> | 384 | 376us | 219us | -41.20%| > >>> | 256 | 421us | 323us | -23.28%| > >>> | 128 | 523us | 507us | -3.06%| > >>> > >>> Of course, alloc_charge_hpage() will take longer to run with > >>> the __GFP_ZERO flag. > >>> > >>> | Func | w/o __GFP_ZERO | w/ __GFP_ZERO | > >>> |----------------------|----------------|---------------| > >>> | alloc_charge_hpage | 198us | 295us | > >>> > >>> But it's not a big deal because it doesn't impact the total > >>> time spent by khugepaged in collapsing a hugepage. In fact, > >>> it would decrease. > >> > >> It does look sane to me and not overly complicated. > >> > >> But, it's an optimization really only when we have quite a bunch of > >> pte_none(), possibly repeatedly so that it really makes a difference. > >> > >> Usually, when we repeatedly collapse that many pte_none() we're just > >> wasting a lot of memory and should re-evaluate life choices :) > > > > Agreed! It seems that the default value of max_pte_none may be set too > > high, which could result in the memory wastage issue we're discussing. > > IIRC, some companies disable it completely (set to 0) because of that. > > > > >> > >> So my question is: do we really care about it that much that we care t= o > >> optimize? > > > > IMO, although it may not be our main concern, reducing the impact of > > khugepaged on the process remains crucial. I think that users also pref= er > > minimal interference from khugepaged. > > The problem I am having with this is that for the *common* case where we > have a small number of pte_none(), we cannot really optimize because we > have to perform the copy. > > So this feels like we're rather optimizing a corner case, and I am not > so sure if that is really worth it. > > Other thoughts? Another thought is to introduce khugepaged/alloc_zeroed_hpage for THP sysfs settings. This would enable users to decide whether to avoid unnecess= ary copies when nr_ptes_none > 0. > > -- > Cheers, > > David / dhildenb >