mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Vitalii Bursov <vitaly@bursov.com>
To: Valentin Schneider <vschneid@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Daniel Bristot de Oliveira <bristot@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 2/3] sched/debug: dump domains' level
Date: Thu, 4 Apr 2024 17:55:06 +0300	[thread overview]
Message-ID: <9a27afea-046d-45f3-9ac4-98ccfd637068@bursov.com> (raw)
In-Reply-To: <xhsmh34s1b43e.mognet@vschneid-thinkpadt14sgen2i.remote.csb>



On 04.04.24 17:21, Valentin Schneider wrote:
> On 03/04/24 16:28, Vitalii Bursov wrote:
>> Knowing domain's level exactly can be useful when setting
>> relax_domain_level or cpuset.sched_relax_domain_level
>>
>> Usage:
>> cat /debug/sched/domains/cpu0/domain1/level
>> to dump cpu0 domain1's level.
>>
>> Signed-off-by: Vitalii Bursov <vitaly@bursov.com>
>> ---
>>  kernel/sched/debug.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
>> index 8d5d98a5834d..c1eb9a1afd13 100644
>> --- a/kernel/sched/debug.c
>> +++ b/kernel/sched/debug.c
>> @@ -425,6 +425,7 @@ static void register_sd(struct sched_domain *sd, struct dentry *parent)
>>
>>       debugfs_create_file("flags", 0444, parent, &sd->flags, &sd_flags_fops);
>>       debugfs_create_file("groups_flags", 0444, parent, &sd->groups->flags, &sd_flags_fops);
>> +	debugfs_create_u32("level", 0444, parent, (u32 *)&sd->level);
> 
> How about reusing the SDM macro? ->flags and ->groups_flags get special
> treatment for pretty printing, but the others don't need that.
> ---
> diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
> index c1eb9a1afd13e..f97902208b34d 100644
> --- a/kernel/sched/debug.c
> +++ b/kernel/sched/debug.c
> @@ -419,13 +419,13 @@ static void register_sd(struct sched_domain *sd, struct dentry *parent)
>  	SDM(u32,   0644, busy_factor);
>  	SDM(u32,   0644, imbalance_pct);
>  	SDM(u32,   0644, cache_nice_tries);
> +	SDM(u32,   0444, level);
>  	SDM(str,   0444, name);
>  
>  #undef SDM
>  
>  	debugfs_create_file("flags", 0444, parent, &sd->flags, &sd_flags_fops);
>  	debugfs_create_file("groups_flags", 0444, parent, &sd->groups->flags, &sd_flags_fops);
> -	debugfs_create_u32("level", 0444, parent, (u32 *)&sd->level);
>  }
>  
>  void update_sched_domain_debugfs(void)
> 

This worked when I tried it. The reason why I chose an explicit implementation
with debugfs_create_u32() is because "level" is "int" and there's no
debugfs_create_{s32,int}(). While casting is not the best option either, it
hints that types mismatch.

In a few other cases when types do not match, casting is usually used. e.g.
mod_debug_add_ulong macro in kernel/module/stats.c:
#define mod_debug_add_ulong(name) debugfs_create_ulong(#name, 0400, mod_debugfs_root, (unsigned long *) &name.counter)
where "counter" can be s64 from the atomic64.

Thanks

  reply	other threads:[~2024-04-04 15:10 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-03 13:28 [PATCH v3 0/3] sched/fair: allow disabling sched_balance_newidle with sched_relax_domain_level Vitalii Bursov
2024-04-03 13:28 ` [PATCH v3 1/3] " Vitalii Bursov
2024-04-04 14:14   ` Valentin Schneider
2024-04-04 15:10     ` Vincent Guittot
2024-04-03 13:28 ` [PATCH v3 2/3] sched/debug: dump domains' level Vitalii Bursov
2024-04-04 12:26   ` Vincent Guittot
2024-04-04 14:21   ` Valentin Schneider
2024-04-04 14:55     ` Vitalii Bursov [this message]
2024-04-03 13:28 ` [PATCH v3 3/3] docs: cgroup-v1: clarify that domain levels are system-specific Vitalii Bursov
2024-04-04 12:26   ` Vincent Guittot
2024-04-04 14:22   ` Valentin Schneider
2024-04-05  9:17 ` [PATCH v3 0/3] sched/fair: allow disabling sched_balance_newidle with sched_relax_domain_level Dietmar Eggemann
2024-04-05 10:25   ` Vitalii Bursov
2024-04-05 10:59     ` Dietmar Eggemann

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=9a27afea-046d-45f3-9ac4-98ccfd637068@bursov.com \
    --to=vitaly@bursov.com \
    --cc=bristot@redhat.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    /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

Powered by JetHome