All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michal Koutný" <mkoutny@suse.com>
To: Albert Esteve <aesteve@redhat.com>
Cc: Tejun Heo <tj@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>,
	 Shuah Khan <shuah@kernel.org>,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
	 linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v5 1/4] cgroup: Add dmem_selftest module
Date: Mon, 24 Aug 2026 20:28:32 +0200	[thread overview]
Message-ID: <aoyFYWYmocJkTeXk@localhost.localdomain> (raw)
In-Reply-To: <20260706-kunit_cgroups-v5-1-6c42c8753468@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]

On Mon, Jul 06, 2026 at 02:06:40PM +0200, Albert Esteve <aesteve@redhat.com> wrote:
> Currently, dmem charging is driver-driven through direct
> calls to dmem_cgroup_try_charge(), so cgroup selftests
> do not have a generic way to trigger charge and uncharge
> paths from userspace.
> 
> This limits any selftest coverage to configuration/readout
> checks unless a specific driver exposing charge hooks is
> present in the test environment.

What about that
drivers/gpu/drm/ttm/tests/ttm_resource_test.c
?

> 
> Add kernel/cgroup/dmem_selftest.c as a helper module
> (CONFIG_DMEM_SELFTEST) that registers a synthetic dmem region
> (dmem_selftest) and exposes debugfs control files:
> /sys/kernel/debug/dmem_selftest/charge
> /sys/kernel/debug/dmem_selftest/uncharge

Nit: I'd think about alloc and free (to denote meaning not how it's
implemented). 

> 
> Writing a size to charge triggers dmem_cgroup_try_charge() for
> the calling task's cgroup (the module calls kstrtou64()).
> Writing to uncharge releases the outstanding charge via
> dmem_cgroup_uncharge(). Only a single outstanding charge
> is supported.
> 
> This provides a deterministic, driver-independent mechanism
> for exercising dmem accounting paths in selftests.
> 
> Signed-off-by: Albert Esteve <aesteve@redhat.com>
> ---
>  init/Kconfig                  |  12 +++
>  kernel/cgroup/Makefile        |   1 +
>  kernel/cgroup/dmem_selftest.c | 198 ++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 211 insertions(+)
> 
> diff --git a/init/Kconfig b/init/Kconfig
> index 5230d4879b1c8..6fab65d6b44ea 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1267,6 +1267,18 @@ config CGROUP_DMEM
>  	  As an example, it allows you to restrict VRAM usage for applications
>  	  in the DRM subsystem.
>  
> +config DMEM_SELFTEST
> +	tristate "dmem cgroup selftest helper module"
> +	depends on CGROUP_DMEM && DEBUG_FS
> +	default n
> +	help
> +	  Builds a small loadable module that registers a dmem region named
> +	  "dmem_selftest" and exposes debugfs files under
> +	  /sys/kernel/debug/dmem_selftest/ so kselftests can trigger
> +	  dmem charge/uncharge operations from userspace.
> +
> +	  Say N unless you run dmem selftests or develop the dmem controller.

Could this be made w/out introduciton of a new Kconfig option? (E.g.
what tools/testing/selftests/livepatch/test_modules/Makefile does)

(Maybe reword to insmod if you choose building the test module as OOT.)

> +static int __init dmem_selftest_register(void)

Just an idea to reduce the amount debugfs of boilerplage -- the testing
args could be handled by module_param_cb().

> +static int __init dmem_selftest_init(void)
...
> +	add_taint(TAINT_TEST, LOCKDEP_STILL_OK);

Great!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

  parent reply	other threads:[~2026-08-24 18:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-06 12:06 [PATCH v5 0/4] cgroup: dmem: add selftest helper, coverage, and VM runner Albert Esteve
2026-07-06 12:06 ` [PATCH v5 1/4] cgroup: Add dmem_selftest module Albert Esteve
2026-07-09 13:26   ` Eric Chanudet
2026-08-24 18:28   ` Michal Koutný [this message]
2026-08-31 11:23     ` Albert Esteve
2026-07-06 12:06 ` [PATCH v5 2/4] selftests: cgroup: Add dmem selftest coverage Albert Esteve
2026-07-09 13:31   ` Eric Chanudet
2026-08-24 18:28   ` Michal Koutný
2026-08-31 12:33     ` Albert Esteve
2026-07-06 12:06 ` [PATCH v5 3/4] selftests: cgroup: Add vmtest-dmem runner script Albert Esteve
2026-07-09 13:45   ` Eric Chanudet
2026-07-06 12:06 ` [PATCH v5 4/4] selftests: cgroup: handle vmtest-dmem -b to test locally built kernel Albert Esteve
2026-08-24 18:27 ` [PATCH v5 0/4] cgroup: dmem: add selftest helper, coverage, and VM runner Michal Koutný
2026-08-31  8:45   ` Albert Esteve

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=aoyFYWYmocJkTeXk@localhost.localdomain \
    --to=mkoutny@suse.com \
    --cc=aesteve@redhat.com \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=shuah@kernel.org \
    --cc=tj@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.