linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: SeongJae Park <sj@kernel.org>,
	damon@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org
Subject: [PATCH 0/5] mm/damon: hide kdamond and kdamond_lock from API callers
Date: Thu, 15 Jan 2026 07:20:40 -0800	[thread overview]
Message-ID: <20260115152047.68415-1-sj@kernel.org> (raw)

'kdamond' and 'kdamond_lock' fields initially exposed to DAMON API
callers for flexible synchronization and use cases.  As DAMON API became
somewhat complicated compared to the early days, Keeping those exposed
could only encourage the API callers to invent more creative but
complicated and difficult-to-debug use cases.

Fortunately DAMON API callers didn't invent that many creative use
cases.  There exist only two use cases of 'kdamond' and 'kdamond_lock'.
Finding whether the kdamond is actively running, and getting the pid of
the kdamond.  For the first use case, a dedicated API function, namely
'damon_is_running()' is provided, and all DAMON API callers are using
the function for the use case.  Hence only the second use case is where
the fields are directly being used by DAMON API callers.

To prevent future invention of complicated and erroneous use cases of
the fields, hide the fields from the API callers.  For that, provide new
dedicated DAMON API functions for the remaining use case, namely
damon_kdamond_pid(), migrate DAMON API callers to use the new function,
and mark the fields as private fields.

SeongJae Park (5):
  mm/damon/core: implement damon_kdamond_pid()
  mm/damon/sysfs: use damon_kdamond_pid()
  mm/damon/lru_sort: use damon_kdamond_pid()
  mm/damon/reclaim: use damon_kdamond_pid()
  mm/damon: hide kdamond and kdamond_lock of damon_ctx

 include/linux/damon.h | 30 +++++++++++++++---------------
 mm/damon/core.c       | 17 +++++++++++++++++
 mm/damon/lru_sort.c   |  4 +++-
 mm/damon/reclaim.c    |  4 +++-
 mm/damon/sysfs.c      |  7 +++----
 5 files changed, 41 insertions(+), 21 deletions(-)


base-commit: 1aebb6fcfd6a8da57a4eda7863d69e533c392ae0
-- 
2.47.3


             reply	other threads:[~2026-01-15 15:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-15 15:20 SeongJae Park [this message]
2026-01-15 15:20 ` [PATCH 1/5] mm/damon/core: implement damon_kdamond_pid() SeongJae Park
2026-01-15 15:20 ` [PATCH 2/5] mm/damon/sysfs: use damon_kdamond_pid() SeongJae Park
2026-01-15 15:20 ` [PATCH 3/5] mm/damon/lru_sort: " SeongJae Park
2026-01-15 15:20 ` [PATCH 4/5] mm/damon/reclaim: " SeongJae Park
2026-01-15 15:20 ` [PATCH 5/5] mm/damon: hide kdamond and kdamond_lock of damon_ctx SeongJae Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260115152047.68415-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=damon@lists.linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox