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 B8650C48BEB for ; Wed, 21 Feb 2024 22:12:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F2D206B0081; Wed, 21 Feb 2024 17:12:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EDD3A6B0082; Wed, 21 Feb 2024 17:12:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DCB9D6B0083; Wed, 21 Feb 2024 17:12:05 -0500 (EST) 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 CDD5C6B0081 for ; Wed, 21 Feb 2024 17:12:05 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 70D30A1043 for ; Wed, 21 Feb 2024 22:12:05 +0000 (UTC) X-FDA: 81817209810.19.6F8D3C8 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf08.hostedemail.com (Postfix) with ESMTP id 0766A160005 for ; Wed, 21 Feb 2024 22:12:02 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=u7udHJWe; spf=pass (imf08.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708553523; 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=2d7uVvKN+LoalBGOWxlCwwPCicHBRmXZZJ546EfyRKw=; b=0MqnpmsDLJ+RR7bRSdBuFKgmLXP32Ileq8E+d26abF000IDZU4IhLMARYNr4eloe8MMkZk M5yALlN28rOvhTCYeXp254T28F4SsdTy5j3m2cHchz6Xqxr7+MPmKyIC6CzmPTf5avse6b l3ydVu66L/3yC3fldqwM1LguKbl7mI4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708553523; a=rsa-sha256; cv=none; b=0ztDx+7tZzYYFbs6k3TdS0tQvEHuNni6H0f1BNJlPqx5qxcYxkUtRmzNfpZ/h5wqq0HZ7M O3CbuCVLWwqVmU8PWT11+XAiKUVTZpA2ZqDgO04FK6bH4dmK798XkEMVvMdeAaqP27j/WN 0JqWVi0o8BcC88X9BxSabqC6+BPi1Po= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=u7udHJWe; spf=pass (imf08.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id AE81BCE1305; Wed, 21 Feb 2024 22:11:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 936BEC433F1; Wed, 21 Feb 2024 22:11:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1708553518; bh=MpuFyYpFGbhwPH3WeRDv8S0Vma53RRU34+TszDKayw4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=u7udHJWeb4Lxq2B0dedbNkNBduktONYRoy1qUKS3shYfrrB1Tto8nzQhCkK/CgzGG 2N6HZCRpqLVVuIYQUEkPkzZzevfnV0Ej2LGiKTttHjW2zfdAAcjUQ4cWxR+P1I/cJx SoHUXJnoMdCBtrAvLzJVxe7oK5Rop3s7QihEVv14= Date: Wed, 21 Feb 2024 14:11:58 -0800 From: Andrew Morton To: Lance Yang Cc: mhocko@suse.com, zokeefe@google.com, david@redhat.com, songmuchun@bytedance.com, shy828301@gmail.com, peterx@redhat.com, minchan@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/1] mm/khugepaged: bypassing unnecessary scans with MMF_DISABLE_THP check Message-Id: <20240221141158.8217ff2caf4f86c11a430058@linux-foundation.org> In-Reply-To: References: <20240129054551.57728-1-ioworker0@gmail.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0766A160005 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 8rgdr19rg6tyfnitieb6w1xbd36mkfcd X-HE-Tag: 1708553522-138335 X-HE-Meta: U2FsdGVkX19mv0Q3VIbfm9prQ2QA17Usenyiw35Vw/UxUcleMOF/JvDENZvVlOxgXTUWROT68D8nrRlvhyLgdOV9IFUBpMnzs/hqZjwmFeksvQ5mXMc2qAzU0UTlMjBI4CDtILnPiEGGgA6ybadTGaU2RMTfqRapMqn9XhcrQr/bW5XFmYb7sw5BppeFiNNCEexWs6JdbHDyL+Q+15goixJNICS5l8JWLL4rNUykTlITth4FVrrMFegnB50K+dWHy5Ro/WJIBwaCYm8DeKkdMnYgkdno+OKQG/uCYMJBaZZA7QHk56EXuSw7fs3jmQsnHJNxvbs5leQuPk/HCPah7uhCVHLBl/8p5BB5Y6+4JQ2Tk2y5G8ItnEwnh3rubWyzWTMDAksF54Un2o7cdFpfQoeLFPUQ8zrvedBBSS+1EgVILJpfywth+yLwp1rYFR3TO2pe59eivGqEUhlyUKbtmd8+iIcseBFJewpjHu2G+yS5cYT+cfTwSi1Zj8gdIMVSuAnJwPpnRFeSVYMRsh1mHe5pP1uvi1pGgNbv+M0Ufbo0kQsNCY8S/cwSOyR/24CoiUj8M2fxwDlPh1d2B3UPUc8UtcPxJs6OgzD3AxFQ75HZfoLP1how4KnRb4PXQvSYuMn8xGN7fRicy4U7qClbcb2aTy0vdyBRqSJrRd/3EH2iC3mKfABGaTwvDWszYoSAloHtht12z8qAR+Zt3fJGARlvfpY/OZhJdCIn+rRvAdFNhtLPhb+qLxNJ8SrYPrTTv71k9/uzfRJaPblh+MJgJAs+m1QQNjeuPC7ZZ5euXWLZft/TGjMBmp0H5+CHlVaXYEvTHIXtnBuFUtX5UaDLHC2RMQ6FYTWUDZXH7VN3AXBDkzzV/BiXoQPcMUwGp9IsWFC19pHhrpIDd4ZeB9OpS52A/8XPp2wcZCs4CZiurpM2JTwi4AXUyHuJEVU2z3uHVDKHAYrqyseb+ULuQsh 8XLyfdo7 RBO9w 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, 31 Jan 2024 17:30:11 +0800 Lance Yang wrote: > Updating the change log. > > khugepaged scans the entire address space in the > background for each given mm, looking for > opportunities to merge sequences of basic pages > into huge pages. However, when an mm is inserted > to the mm_slots list, and the MMF_DISABLE_THP > flag is set later, this scanning process becomes > unnecessary for that mm and can be skipped to > avoid redundant operations, especially in scenarios > with a large address space. > > This commit introduces a check before each scanning > process to test the MMF_DISABLE_THP flag for the > given mm; if the flag is set, the scanning process is > bypassed, thereby improving the efficiency of khugepaged. > > This optimization is not a correctness issue but rather an > enhancement to save expensive checks on each VMA > when userspace cannot prctl itself before spawning > into the new process. > > On some servers within our company, we deploy a > daemon responsible for monitoring and updating local > applications. Some applications prefer not to use THP, > so the daemon calls prctl to disable THP before fork/exec. > Conversely, for other applications, the daemon calls prctl > to enable THP before fork/exec. > > Ideally, the daemon should invoke prctl after the fork, > but its current implementation follows the described > approach. In the Go standard library, there is no direct > encapsulation of the fork system call; instead, fork and > execve are combined into one through syscall.ForkExec. I pasted the above into the v1 patch's changelog. However I'm not seeing a good level of reviewer enthusiasm. Pertially because of the lack of quantitative testing results. Is is possible to generate such results, to give people an overall feel of the desirability of this change?