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 1C481C02182 for ; Tue, 21 Jan 2025 20:05:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 854BE6B0085; Tue, 21 Jan 2025 15:05:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7DDCD6B0088; Tue, 21 Jan 2025 15:05:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6873A280001; Tue, 21 Jan 2025 15:05:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 48DEE6B0085 for ; Tue, 21 Jan 2025 15:05:17 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B12DE80D87 for ; Tue, 21 Jan 2025 20:05:16 +0000 (UTC) X-FDA: 83032538232.23.9C5D1D9 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf18.hostedemail.com (Postfix) with ESMTP id EDF4F1C0005 for ; Tue, 21 Jan 2025 20:05:14 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=SccMQ2IK; spf=pass (imf18.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737489915; 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=aLoXV9kn/2kxDXCOg3rWJxIFm8ou+jseT+MMzt98iM8=; b=o0IvCd62BuNWZtOfJTmSW1bqsi7r58jdSeqHSrD9Uzay6qnR9ATltib9zT6XDcOUz+j8kr Pixdn0vqsiixvZxgQzR0gHG0ezx9m29zkuRhbINUxiz04lPX5gtreQCojsjzv2sjYMJq0G EcznYDn/59draIdLJ8IkBIV/PGCV6Bg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737489915; a=rsa-sha256; cv=none; b=u4WhXbwwsWLLFhHMn6LMSq4TUzzDfu7x2Qf3QkSw7+JyskjK9ZOaTzeBpEiQs3P7uqqoxP czedI7fK4pciN8cO1XPyVYQENur6ST7hpbeLvMgbRUJtPyaJDJxztE//MbKUKASrILneE4 1pjrJcn4sVvwVWMqaZe1r/G9U0Ff0tE= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=SccMQ2IK; spf=pass (imf18.hostedemail.com: domain of sj@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 9D4BEA41FF5; Tue, 21 Jan 2025 20:03:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B13F5C4CEDF; Tue, 21 Jan 2025 20:05:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1737489913; bh=4OwJPXofw0b0X9F6vhLLxhsdWEct6cZHoBaImZIMFtU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=SccMQ2IKJdTXa/ezGZbhR2XYstUuMFqp3aQkb1KOxtP+EgWtEbqQtnMuNc2ix1sfO wCZkM9OPMY3pRoe6hnoETF0vb7TWEnBOgMpm8spyfsyXzCy1eiz/dmRID9r3xxQ6yZ 8gVKkU5nleudWNgo6xoCCOWPcpVeaCAKO+YfbLKIJTw5D28O2AGLNpL+gAUh9wM+NP 3ZSFovG/SL2DCQw9kDbR+P6muGSY/wYT7ESKPnl6MtMoXHRUx5f8i9EGjrbFk1oPN0 Rqf+iQAcYH16QDFgnUsOFki5XEQ2HCPnOGYy25qHo4C5cFEMrer3+tJ8UWRg/FKR5Q VS/0+L/8B9IEw== From: SeongJae Park To: David Hildenbrand Cc: SeongJae Park , Usama Arif , akpm@linux-foundation.org, damon@lists.linux.dev, linux-mm@kvack.org Subject: Re: [PATCH v3 2/2] mm/damon: introduce DAMOS filter type hugepage Date: Tue, 21 Jan 2025 12:05:10 -0800 Message-Id: <20250121200510.43645-1-sj@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Stat-Signature: r6psgrtihr6qbc9pt9z5bg9zhwwfoqu7 X-Rspam-User: X-Rspamd-Queue-Id: EDF4F1C0005 X-Rspamd-Server: rspam03 X-HE-Tag: 1737489914-315626 X-HE-Meta: U2FsdGVkX18Xg4vZVC/rIeQ83o4qxvdNt9mV2gWjGpuIwnQxG0URd3FembVY31zIyyuczPvhNRbKIhXb5Di6N44HPRdSSFKyvosxA9mz/tal9o405Dj2/ZSesfrZ4OU6lJrbiD8ZHfQChs0z8EksU7CFyFZttgFKqw3SX24QJUv9Ggx+FnasZDiVirANu2WmElYihHCIGpXohhrDDtJWAiA8/F28Dl55aq+Tgd6XxGisZAlDNic0CTZ1gnJzCabfmjS9eQsnpB978TQoNGChHkcLjQevycM1hOHbYGSkRFAnn8c8DbmNYXldl5iu4jTDTB4WtKD9UWDI8TTDRuTMjyEfHF92Cq9ADDonFinMr2CWsRKk9tA9ZXf17BW6Blymu8iqpQCNeAR/rrGOPJYro7itoHNs+Yj7CUN+40k11qzgUhgs7fyIJjAU7AEmkRfVkldcPQWYKx7lU2jj+zSJgu4RPN7k/AJmOlFYR9CODQztOriBb0ehK9D38fCqBAd+SHrCfQVe1SV0WZNufqyOdkcveO1WawWY4VUvtMdW1ro8RKLu80dSKAqboJE5uPJKQQSmGPTAU4N3/QcF4iPm1cSYCIQCMg8mVCdrIPQmj7RhU2UN7tNx5u3HJlVeE0eydYqztnXbn5pGxImZ85PWNF8XXtRYmys+dF1LLH77hVZ3v/yAChgL6BK2X7ldc5BtJcDEBaDkEzg6ywZAy0DC0K03f3dprh1zZQ1X+3hZAZn61rcnSaNcyf4RvjfjQ9tZOOlE6PfqC7HCmylgjl19doiieel0+efMyXXjOSnfJqFWBBECMEYjhZyyuxzVESETwcFNaVKI7pO96/zXjnF7nQKNQeOBrzbog1q2E27LwNyK4QtIzMFqMP7tXpDvvxLYNVfDvjnjQwlLj1UaHMoLrjy8JMFrYrck25qnfIClC5oKXWF6CzhgUdOo+urSwEoaO9G0k1RQwej9Tbe5blI IysnfmFq 6bFDrQPHxb/Bm8pIOjoqObAePNa7PU83bkcHNleOb0e6GkpXB08eha5gNNfAe27R7UpYMZVQRXRwdxN+EDHQkDbr1psq3WzTeML8MIGzH5nSq66qGPnNX09rABtwaXnwOpmxdiFrVYYF4iHn6SGFh9J+rv+mz5uoYLaYDIKe7+hpy+YrniIY+Bw46nCqFIHf998I4Fcgu9s0kFk9j7yyl13Oee0xNizbPjPxZmwdDnzl3wk4= 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, 21 Jan 2025 19:39:01 +0100 David Hildenbrand wrote: > On 21.01.25 18:52, SeongJae Park wrote: > > On Mon, 20 Jan 2025 21:03:05 +0100 David Hildenbrand wrote: > > > >> On 20.01.25 20:58, Usama Arif wrote: > >>> > >>> > >>> On 20/01/2025 19:30, SeongJae Park wrote: > >>>> On Mon, 20 Jan 2025 20:23:20 +0100 David Hildenbrand wrote: > >>>> > >>>>> On 20.01.25 20:16, SeongJae Park wrote: > >>>>>> On Mon, 20 Jan 2025 19:57:10 +0100 David Hildenbrand wrote: > >>>>>> > >>>>>>> On 20.01.25 19:19, Usama Arif wrote: > >>>> [...] > >>>>>>>> +#if defined(CONFIG_PGTABLE_HAS_HUGE_LEAVES) > >>>>>>>> + case DAMOS_FILTER_TYPE_HUGEPAGE: > >>>>>>>> + matched = folio_size(folio) == HPAGE_PMD_SIZE; > >>>>>>> > >>>>>>> > >>>>>>> Can we directly embed in the name and the comments/docs that we are only > >>>>>>> talking about PMD size (both, THP and hugetlb)? > >>>>>>> > >>>>>>> DAMOS_FILTER_TYPE_PMD_HUGEPAGE or sth. like that. > >>>>>> > >>>>>> Nice suggestion, thank you! And we might later add more filter types for > >>>>>> different size huge pages. What about extending this to handle more general > >>>>>> case, though? That is, we can let the filter receives a range of the folio > >>>>>> size to match, like DAMOS_FILTER_TYPE_ADDR does. Then, the filter could be > >>>>>> used for any size of interest. > >>>>> > >>>>> That would probably be future proof: either a range or explicitly > >>>>> specified sizes (ranges?). > >>>> > >>>> DAMON supports installing multiple DAMOS filters. So multiple DAMOS filters > >>>> that each matching single range can be used for the multiple sizes or ranges > >>>> use case. > >>>> > >>>> > >>> > >>> Does creating something like schemes//access_pattern/page_size/{min,max} > >>> sound good? with the default value being pmd size? > >> > >> "page_size" might be misleading. > > > > Good point. I'm suggesting to add the files on another directory, and > > apparently Usama agrees[1]. So the term "page_size" will not be used. > > > >> Not sure if we want to use the word > >> "folio_size" here, so far it's more an internal detail that evolved from > >> compound pages. > >> > >> "hugepage_size" would at least match /sys/kernel/mm/hugepages/ and > >> /sys/kernel/mm/transparent_hugepage/. > >> > >> But if you would also support "single page" == e.g., 4K, "hugepage" > >> would be wrong. > > > > Again, nice points, thank you for letting us aware of this. We could error > > users if they try to set <=PAGE_SIZE filter range. FYI, DAMOS filters supports > > making the filtering in/out action for not only condition-matching memory, but > > also not-matching memory, so it will still be able to be used for filtering > > in/out base pages. > > > > That said, I now think "folio_size" might be a better term that allows simple > > implementation and flexible usages. > > The issue with "folio" is that it is mostly a kernel-internal name for > how we currently manage metadata for all pages and compound pages. In > the future, some of what we call folio today will no longer be called > folios ... as soon as we dynamically allocate "struct folio". Agreed. I'd suggest using "hugepage_size" or "hugepage" filter type name, then. I have no strong preferrence between the two names. Also, to have a flexible usage and a simple logic, let's not error users for wrong input, but just define the filter type as "match" if the folio is "huge AND the size is in the given range". Then we can allow users set <=PAGE_SIZE range but make it just works as sanely expected, like below. static bool damos_pa_filter_match(struct damos_filter *filter, [...] case DAMOS_FILTER_TYPE_HUGEPAGE_SIZE: size_t sz = folio_size(folio); if (sz <= PAGE_SIZE) matched = false; else matched = filter->min <= sz && sz <= filter->max; break; Thanks, SJ [...]