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 4860DC02192 for ; Wed, 5 Feb 2025 22:05:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB0B56B0089; Wed, 5 Feb 2025 17:05:33 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A5FD36B0092; Wed, 5 Feb 2025 17:05:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 927F06B0093; Wed, 5 Feb 2025 17:05:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 7489E6B0089 for ; Wed, 5 Feb 2025 17:05:33 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 23B18160B41 for ; Wed, 5 Feb 2025 22:05:33 +0000 (UTC) X-FDA: 83087273346.15.B8FA165 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf15.hostedemail.com (Postfix) with ESMTP id 6E7D3A001A for ; Wed, 5 Feb 2025 22:05:31 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="HKhUA/Xq"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738793131; a=rsa-sha256; cv=none; b=ApmTSshlVrpzm5Q4uwCwOBpUUV3t8Ro+c8cJYtvne6RQbOehBEDR1954x3XY9kxb6b1d+o 0vb4QZQXwAB0hdUKZbQQ1OXh/DGHAb7Gaxcq/RlkklJZ9rvfG8/EyuxnfSy19+rkTgh+QG OEJdwirZfpyl6YppshMx1wtwAFbREYI= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="HKhUA/Xq"; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf15.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738793131; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7Hog0L0U8zXiycwd5wGcVfb2lEppt6+hyQnTJkFt8GM=; b=iWDo4j/mvJCAFZ0QSBy3bh5GcEaZ+PQNZHVMOluXHyzftqFvFmjKD9Fgbt90jG71oULyUN kfwn67p/N5QCwTiPW3lq9G9AWh0QeQvmOQ3e87L5bPT/ESoUxW0fUF3I0mk5qjnasRLptV Ai+KM/Lg1DDpJ1xTx/tUKwS6AfNTp3M= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id A0651A43338; Wed, 5 Feb 2025 22:03:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AE43C4CED1; Wed, 5 Feb 2025 22:05:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738793130; bh=XVzRJVi7hVpCHr4wEdIMv0ZBwmAPeB7hb58ATE1IIJE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=HKhUA/XqcjyrJTKhaor5M6A8u1GjPz9xDbt0JWEldUEq79Y+yIbrDW4AdwnYma01c kr9PSrhYq25W+8GI4Vu5WUck18+O8BfONsND9ECQwr69+qnRisus80wpRVKxfXk37J 0mc7/4hzPDALmGBxfQOYBm4ObMnRjvWM4zIRJLdFNc/pOs2lVrjFY3q4QKuhHwuugx cNUXUH9R1bh7ei8naM35k9hvtJq+xlRVfft9RBgCoyZYWJ3zASJRDcjZNWnJmkw1P0 bkuRdm0hxRG0aKV8TpdPcBrZckDSdzKeaP8fpKsLKBWJvmX7AUCerMOx/gYh1DWLNn CfIk/xWhIWCcA== From: SeongJae Park To: Usama Arif Cc: SeongJae Park , akpm@linux-foundation.org, damon@lists.linux.dev, linux-mm@kvack.org, hannes@cmpxchg.org, david@redhat.com, kernel-team@meta.com Subject: Re: [PATCH v4 4/6] mm/damon: introduce DAMOS filter type hugepage Date: Wed, 5 Feb 2025 14:05:27 -0800 Message-Id: <20250205220527.60313-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <49382f59-afea-41b2-8ca5-1bec9fb179dc@gmail.com> References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: 6E7D3A001A X-Rspamd-Server: rspam10 X-Stat-Signature: eefrhrhkgabet585aeujnf86bdq8ttgs X-HE-Tag: 1738793131-768465 X-HE-Meta: U2FsdGVkX19U+LRrkjl1l+KTuiQP40tGamnn0x42QRcAA1CUZ7F07OKZiSs59srPo/zY7oeBNzw0zRmvAbkPsNfVp3zr/A3yENEsL21ofyRKAH8XWuu7kxFlABYM9p6wudilUxss1ynrh5/+GAr7Sn0GUIuXtvI6KtmpttvJhkW7hHLX1hIqusuyjMERik+5zmLEv0OMDwFKhHMsASjK39AbqmHgyDhvSC4u5OJXa+1o1wJ8LvoQq5WoA529oO+hfU/JdId25oO+gQnRWXquTFzlLTXtIhiYEVU/yvoHQImQ962Yg60FjBbdQIHtd/qzGsIHLVee2a4UbYGzVgiI2jtVSmsOLEduKdcQ0poWMEeutikKeCEu6uw1PeSD8P4yNpjW1s8jrNdAuvZsfR/TvdcGbYSx+je7+UNkMU6Wpbbqf76z627IFb+JTLhw/fRSWOlcthwcKY4ZEBRWtpbANhrT1Nf844LCYVQRNpKz2Px09kONKU2u9Aj6zsz0OXM2fcKkBZWH8AjC3VTFMqKXRJW9lUtvg3aFWsoDmyJv/ZmUlUv7WFowS5U692Y6+3M9CmrMEENUdrw/wMerrQfXFaMbeeZG2JvdEPwpfxl/7AjQ22Ud9p7qnTWBHanUa8nSioeXt51j+rXnJHdltdMD8bgLrVyhWSVWX8IkDHvshRqGwG79Fxi1zcwRZk18N9fqYnjswrUXxpYI4sAof7/IWw+JC7DU0GrsoPXe+evEsju6nI1ujwmti3hyPF1mqj/boYH9hQRpVUv2ahiw/3Oy873X8H8+ADtJqsqjz8syun2u2qprThM4wSGLBl5OQIDaGMuaUr57OyEFFq9z53/47roN8C68lgpiplKoSfpjblmiwyiz7W3vlQualJ8AdE2hqPUho84dseNaBPY+Tv4OCyQmbpbM6dm/JjdZorQD73BZovvRSKEv8TFJOYgHpwkqIJ+jZrvNyj97YXteLs0 dxupcrnS cQR6xcJVkbmlJHMxsZkT6egSL65lGJYdWnHqhFRGQ/EfSbLUHTIG9sgozDjmHyJXZj1xYdilGikEGpQVQrAuWYfVWQwvuWPN8J6PWg7vdBiPa52phD/YOu6nIqVuU2S4SKAyXjEzzm6ksCf954Ovd6+fFZ80iDhUajpHB4GQo370BRPgwO05LePq0uBoC/+gp7fuBXBMjMuzhdxUL/xGyd3+o0gem3eqqBQ2nilfbAV5+G1DPKieuYVOQWZAh/2Kc5WD8 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, 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, 5 Feb 2025 13:52:37 +0000 Usama Arif wrote: > > > On 04/02/2025 23:12, SeongJae Park wrote: > > On Mon, 3 Feb 2025 22:55:31 +0000 Usama Arif wrote: > > > >> This is to gather statistics to check if memory regions of specific > >> access tempratures are backed by hugepages of a size in a specific > >> range > > > > nit. A period is missed? > > > >> This filter can help to observe and prove the effectivenes of > >> different schemes for shrinking/collapsing hugepages. > >> > >> Signed-off-by: Usama Arif > >> --- [...] > >> --- a/mm/damon/sysfs-schemes.c > >> +++ b/mm/damon/sysfs-schemes.c > >> @@ -330,6 +330,7 @@ static const char * const damon_sysfs_scheme_filter_type_strs[] = { > >> "anon", > >> "memcg", > >> "young", > >> + "hugepage", > > > > hugepage_size? > > > > So from https://lore.kernel.org/all/20250121200510.43645-1-sj@kernel.org/, my understanding > was you didn't have a preference between "hugepage" and "hugepage_size"? You're right. And sorry, I changed my mind. > > I do prefer hugepage over hugepage_size. This is because this is a type of filter, I would > say hugepage_size is not a type, but hugepage is. For e.g. we have anon as type and not > anon_number. And the "size" part is clear from the min and max which is documented in patch > 5 and 6. I agree your points. The meaning of "min" and "max" is well documented. But, not everyone reads the documentation, and human's memory is volatile. Also we might want to further extend DAMOS fitler for other hugepage properties, say, zero-filled hugepage-internal base pages ratio. So now I prefer "hugepage_size". > > TBH my preference would be "folio". What I think we should do is let users input any value > for min and max, as long as max > min, even if its just 4K page. If the user just wants > to know how much of the region is 4K page, they will get it with this. We can still do this, since DAMOS filters work for not only matching memory but also non-matching memory. It's not very intuitive, but at least makes a sense in my opinion. > But as David said, > folio is a kernel concept so might not be best to expose it as sysfs to userspace? > > As folio might not be an option, my preference is going with hugepage, but as its not > an implementation detail and just naming, I am ok to change it to hugepage_size if > you have a strong preference for it. Yes, I'd suggest calling it "hugepage_size". I don't find a problem it will cause, other than the length. Please let me know if I'm missing something, though! Again, sorry for changing my mind after the last discussion. Thanks, SJ [...]