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 A95E3C4167B for ; Mon, 4 Dec 2023 19:57:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 481B36B02DE; Mon, 4 Dec 2023 14:57:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 40AED6B02E6; Mon, 4 Dec 2023 14:57:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2AD026B02F0; Mon, 4 Dec 2023 14:57:44 -0500 (EST) 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 122556B02DE for ; Mon, 4 Dec 2023 14:57:44 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id CE9CB8039A for ; Mon, 4 Dec 2023 19:57:43 +0000 (UTC) X-FDA: 81530196006.15.FCC83E7 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf25.hostedemail.com (Postfix) with ESMTP id B09B4A000B for ; Mon, 4 Dec 2023 19:57:41 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=EqQPOw88; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf25.hostedemail.com: domain of dmaluka@chromium.org designates 209.85.167.43 as permitted sender) smtp.mailfrom=dmaluka@chromium.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701719861; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pZ44r75rrDxswMMFcuYJD1VEZzZvx6HDPBPK48SLeVI=; b=WXjGheP7mRoGXhAzAbnaRHKSAaANhRHk33m+ZYBdJ2DbirfMwz7ZZwwi5E+ej2ovmW3NEf pjIM/7E5JirLzBx1zdkxn0UI+qnTWcVmO13yKDCKoFUG3bTDge3GvwDMKOU8lO9qB1mD7g rdEJpTGaS3Aq2msMUEdvlb6h6vlKClg= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=chromium.org header.s=google header.b=EqQPOw88; dmarc=pass (policy=none) header.from=chromium.org; spf=pass (imf25.hostedemail.com: domain of dmaluka@chromium.org designates 209.85.167.43 as permitted sender) smtp.mailfrom=dmaluka@chromium.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701719861; a=rsa-sha256; cv=none; b=eMztPJF/DxIUAtuhme7bNSZLQhNH4bq8H7MU6CyENb3BwbVfbz4L0pO6kwwe/CldkGnW8W S2maFdv1bOpud0/hx2dPAiPZ+J3rfAuRLjMAmiyFUiy1ARV15/tbKkQ++ai5FBxKawE5P6 OuFdcG/kf9YGgIQjc9fZ3Fa1oLlVRIQ= Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-50bdec453c8so3673193e87.3 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=kvack.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=EqQPOw88Q+YXOZDPi9w0md/kAancmsKltFzlbJz6IfGKlx4jds84/MbQTn6MAs6dME RAEt3fRATPZON8kUq3ID9ojWauxHv37WZAL93RhoTC3rn8sjdA4ZhAEShJUfV3sMAOs6 cc2WYVeCgl2vfm7SQfytj163MKKFuSswj32hk= 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=ZHx5VTamQA5f9zfBvj3MsPhZ47i1jUIDie5onIVQQbu7oG1gVgETQ1X8oqUNYTSCCK kAWRN/o5KI+w4yc3SBMFHR+6LkEL5Fh743p3cmtIHN4UjhQ0Ot4WUvO/xrvWWNaZvAje Q4xmRxD9KksfNC5JMmIjEH4uHv9qqjNbEfXGD1hXo64cCP6Bpz1UxRZ7VQ/QJbQRyYY7 oVHMqk/4aL1am0zM+lJd3If6Tm0R2Aq5sqy+Ob089qkYobO0Ud7YArOq77opJVuaY7Tc 43cRQsZYTf223slYhuymRvXDvKYQulxNC3fbssOtgbvOd33TtvXYkoiZpHry2rZtuIGM oq6g== X-Gm-Message-State: AOJu0YzLDSOFwE9fQQprG2B4qsOtYf0+QWkueTZO/4TeOEah5hKObQcN 8ObjxCH6RmFkNYq6ZFOX/R6OICFSL/mCI5BYS9BQLg== 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> X-Rspam-User: X-Stat-Signature: h1ne4a8mpk6yg8asti1bfu4o584dedgt X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: B09B4A000B X-HE-Tag: 1701719861-301957 X-HE-Meta: U2FsdGVkX1+qJRMumxHCF6vtPoxzbAmq2ShVjzLYRwjYccS1lWyPZXmjbk24qqpjbcM5Z7i51G49JNTB8+DOFbgV1hmyI6kVrIHeiMBGh3QU20/VejKHi1j246uUPODzUyudkMVb5Ps4L5gg/TkDi0KdT43u9GflAOdy4by5PmMqmFiGaStVVaf3aGeMKnbke1DI5FjrU5qjovEg2Oy07snwU29HLNuo6yr3PB0YXxfPnSrKrVDzPosbmrbXy0R+/gOl35qev0/CGm8WfLrhZEWnsLkrxnF7G/Dvdj9soDWPKhnshmoEyx5UAuRXBie5HHTW3/uvBXeC1V6ql73YR4OAQGBWKo4k/HwEV/Mc82wZUmEqfgeYEbZ2+1On17U883hiXCY0cSjyFD3Ywrj0gvc81UlOS7XK39CTpUJ7AbOrM9iEcTC3udooThmyneF6U1/CTHtRrV/x24R3E23U0L+3e/OKGwv/Uxs0GclAS4S19TzOLKfjCExkOeanp5DDaInlxv2b3++Ee9rsY1AfL7tmsyZVDtEDEZ7d9jAHWTOyhDpTlDZK6yW4vWNS1bLb4fiahA6V2w3udoaFzHnaCutodOSrDavDc6YJlNvObLyYIcRKEtYUdEpFmSE7UEABn1Jd+TYsotHkyUkFHSxfP1zJEjJkJdlOAf5+n1O3SpixyH2CyQo9FF2Ef/FZqn8B1L+BJdP7ysEoiJJzAAtpJrgClYTETFazTZI3cn+rLFK8P8zztQvpEJfsIKesIzN/ocgBvF5To252QtbGnOwn+yEganO8KhoUinD/F+stzykArFAT9HKeC8oOEhzmqhppyLxujqi9G16WvBk2H9M+SRZCEsmrHECXb/OIVI4v8oUsWUUk1NXf1hiB/qQUh9AqWI5EAl0uIrHdIg46fA4gDauJe09MBpkeB9Ri19cwAQcU5fLGFcN016YYE01WrXp7Asd8ARe1TDwF3EkUVei IyO9Go78 24WHOW/sWgni22gwr9yn1FNFpOUtH/l5QQQCbIY1KsTeJ/wPkTYUHDZaPk05M//BirP4/wZrx03PIR62fWTwtXclXQNyPmSK2JDAsHQUiClomJ9wRNXTOjjDq0Zstzhb+6HxrVA8eTW4AdOUkcZjd9L5TawM5Rwa3BGUJK225wyAy6cRRfSa1lT1VbvS31KRQW73vWoW9RXADaFD+Zi+aK1/vdAC7eNhCxIJUp/K4t0w93HhXe/yJIUvs1t7kR7/zvbFlqszf9aVpUymlPaZQu7rHm/2VBmKnBeF8XAlyM/W4GvgxbqwB5Um5iM5CarBHXvFc90QVC083XMUpGEgaCPcXV4RCm6Ah8RfeQhVwG9rrLXzdlxjxqIayqZ26i7evfZSRApBMm8+/t1KNPK9S0hxvDxmDM12B62vTCJHg228sM/p7NgM0P7djgYOVk4SZzLA+dbZdozInyyE= 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 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.