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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F68BC10DC3 for ; Mon, 4 Dec 2023 19:57:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233786AbjLDT5i (ORCPT ); Mon, 4 Dec 2023 14:57:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45106 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229983AbjLDT5g (ORCPT ); Mon, 4 Dec 2023 14:57:36 -0500 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F296E6 for ; Mon, 4 Dec 2023 11:57:41 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id 2adb3069b0e04-50bc22c836bso6513216e87.0 for ; Mon, 04 Dec 2023 11:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1701719860; x=1702324660; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=pZ44r75rrDxswMMFcuYJD1VEZzZvx6HDPBPK48SLeVI=; b=D3zb+FiMJnw/lcYwsbb3N/WFq1QCwJEN9L8Q2uk38gGdqGt6xRcM4FlDqhBfpag48e nOz/yJEKQEMaUdaVSDVRarv9Xxq9Jszx6OBY64abGg/qAzHqqeGCJYrGA0+mRI98/RTY YrlwWNbRUomLGkzVJSv4IxvL/dn0wj3lM/Kvo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701719860; x=1702324660; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=pZ44r75rrDxswMMFcuYJD1VEZzZvx6HDPBPK48SLeVI=; b=Jz9qizsshWO0LsPWEzIyvUkUwtPfOE2JFxHOypu/XDiSAGhYbd7p+f7P6eLcInH9iJ CrHJwecjBKnLSmfikLNH2l9s9pZokC9LqnwNqNAAGx+BbJ0jdU4hQ/1V2kMEy4MekU+3 pPiz0pSSo2SYxtqKPCFDwBPaz4DNC9MhChR5a2sS8ixmAPhwXfXvc/zWQhuyhti+gBZK Jw4DKjppViSXuzfZgyZHcB5if4enL+UUkbf4pzccfpESXhu6GCHZ5YsL1Blo70idicMs aFp25IJ3HUAMEXrm7xpMmazBJJoyMThQZ7zAYmd5XclpTt5mkFeAaIuGOCcaQI4yowzX 1n9Q== X-Gm-Message-State: AOJu0YwScOmg+gcWSicYeeOvStm8q9iNgEXF6/gNmPU7+h/ceEds8myM mPNRPdU+i08zNQHi1wWiCHjrDg== X-Google-Smtp-Source: AGHT+IHo8S0v6m+GUWnNhfVJKEHmbKDBTJO7+pWESmv9h/be7AoxM/Z+PfZRyiKquvmWzcbE88JwKw== X-Received: by 2002:a05:6512:1593:b0:50b:fc77:2d51 with SMTP id bp19-20020a056512159300b0050bfc772d51mr903215lfb.45.1701719859776; Mon, 04 Dec 2023 11:57:39 -0800 (PST) Received: from google.com ([83.142.187.84]) by smtp.gmail.com with ESMTPSA id r12-20020ac25a4c000000b0050bf8ddb1c3sm347930lfn.272.2023.12.04.11.57.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Dec 2023 11:57:39 -0800 (PST) Date: Mon, 4 Dec 2023 20:57:33 +0100 From: Dmytro Maluka To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/thp: add CONFIG_TRANSPARENT_HUGEPAGE_NEVER option Message-ID: References: <20231204163254.2636289-1-dmaluka@chromium.org> <20231204111301.7e087b2f851b30121561e8fc@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231204111301.7e087b2f851b30121561e8fc@linux-foundation.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 04, 2023 at 11:13:01AM -0800, Andrew Morton wrote: > On Mon, 4 Dec 2023 17:32:54 +0100 Dmytro Maluka wrote: > > > Add an option to disable transparent hugepages by default, in line with > > the existing transparent_hugepage=never command line setting. > > > > Rationale: khugepaged has its own non-negligible memory cost even if it > > is not used by any applications, since it bumps up vm.min_free_kbytes to > > its own required minimum in set_recommended_min_free_kbytes(). For > > example, on a machine with 4GB RAM, with 3 mm zones and pageblock_order > > == MAX_ORDER, starting khugepaged causes vm.min_free_kbytes increase > > from 8MB to 132MB. > > > > So if we use THP on machines with e.g. >=8GB of memory for better > > performance, but avoid using it on lower-memory machines to avoid its > > memory overhead, then for the same reason we also want to avoid even > > starting khugepaged on those <8GB machines. So with > > CONFIG_TRANSPARENT_HUGEPAGE_NEVER we can use the same kernel image on > > both >=8GB and <8GB machines, with THP support enabled but khugepaged > > not started by default. The userspace can then decide to enable THP > > (i.e. start khugepaged) via sysfs if needed, based on the total amount > > of memory. > > > > This could also be achieved with the existing transparent_hugepage=never > > setting in the kernel command line instead. But it seems cleaner to > > avoid tweaking the command line for such a basic setting. > > > > P.S. I see that CONFIG_TRANSPARENT_HUGEPAGE_NEVER was already proposed > > in the past [1] but without an explanation of the purpose. > > > > ... > > > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -859,6 +859,12 @@ choice > > madvise(MADV_HUGEPAGE) but it won't risk to increase the > > memory footprint of applications without a guaranteed > > benefit. > > + > > + config TRANSPARENT_HUGEPAGE_NEVER > > + bool "never" > > + help > > + Disabling Transparent Hugepage by default. It can still be > > s/Disabling/Disable/ It is in line with the descriptions of TRANSPARENT_HUGEPAGE_ALWAYS and TRANSPARENT_HUGEPAGE_MADVISE: "Enabling Transparent Hugepage ..." > > + enabled at runtime via sysfs. > > endchoice > > The patch adds the config option but doesn't use it? I should have been more precise: it is not a new option but a new choice for CONFIG_TRANSPARENT_HUGEPAGE, in addition to the existing ALWAYS and MADVISE choices. In mm/huge_memory.c in the declaration of the transparent_hugepage_flags variable, if either ALWAYS or MADVISE is chosen, transparent_hugepage_flags is initialized with such a value that makes khugepaged being started by default during bootup. This patch allows enabling CONFIG_TRANSPARENT_HUGEPAGE without setting either ALWAYS or MADVISE, so that transparent_hugepage_flags is initialized with such a value that khugepaged is not started by default.