From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Tvrtko Ursulin <tursulin@igalia.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
kernel-dev@igalia.com, Huang Ying <ying.huang@intel.com>,
Mel Gorman <mgorman@suse.de>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Rik van Riel <riel@surriel.com>,
Johannes Weiner <hannes@cmpxchg.org>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Dave Hansen <dave.hansen@intel.com>,
Andi Kleen <ak@linux.intel.com>, Michal Hocko <mhocko@suse.com>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH] mm/numa_balancing: Teach mpol_to_str about the balancing mode
Date: Fri, 28 Jun 2024 10:03:37 +0100 [thread overview]
Message-ID: <03641edd-3975-433e-a8d7-d79cb422dc57@igalia.com> (raw)
In-Reply-To: <20240627143719.86a92240516e689c2f2d1c09@linux-foundation.org>
On 27/06/2024 22:37, Andrew Morton wrote:
> On Tue, 25 Jun 2024 14:26:05 +0100 Tvrtko Ursulin <tursulin@igalia.com> wrote:
>
>> From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
>>
>> If a task has had MPOL_F_NUMA_BALANCING set it is useful to show that in
>> procfs. Teach the mpol_to_str helper about its existance and while at it
>> update the comment to account for "weighted interleave" when suggesting
>> a recommended buffer size.
>>
>> ...
>>
>> --- a/mm/mempolicy.c
>> +++ b/mm/mempolicy.c
>> @@ -3293,8 +3293,9 @@ int mpol_parse_str(char *str, struct mempolicy **mpol)
>> * @pol: pointer to mempolicy to be formatted
>> *
>> * Convert @pol into a string. If @buffer is too short, truncate the string.
>> - * Recommend a @maxlen of at least 32 for the longest mode, "interleave", the
>> - * longest flag, "relative", and to display at least a few node ids.
>> + * Recommend a @maxlen of at least 42 for the longest mode, "weighted
>> + * interleave", the longest flag, "balancing", and to display at least a few
>> + * node ids.
>> */
>> void mpol_to_str(char *buffer, int maxlen, struct mempolicy *pol)
>> {
>> @@ -3331,12 +3332,15 @@ void mpol_to_str(char *buffer, int maxlen, struct mempolicy *pol)
>> p += snprintf(p, buffer + maxlen - p, "=");
>>
>> /*
>> - * Currently, the only defined flags are mutually exclusive
>> + * The below two flags are mutually exclusive:
>> */
>> if (flags & MPOL_F_STATIC_NODES)
>> p += snprintf(p, buffer + maxlen - p, "static");
>> else if (flags & MPOL_F_RELATIVE_NODES)
>> p += snprintf(p, buffer + maxlen - p, "relative");
>> +
>> + if (flags & MPOL_F_NUMA_BALANCING)
>> + p += snprintf(p, buffer + maxlen - p, "balancing");
>> }
>>
>> if (!nodes_empty(nodes))
>
> Is it strange to report this via mount options? `static' and
> `relative' can be set via mount options but afaict `balancing' cannot?
> I guess not...
>
> Documentation/filesystems/tmpfs.rst appears to be a suitable place to
> document this new userspace API please.
That was the part I was unsure of - whether it makes sense to allow
passing in 'balancing' via tmpfs.
I just noticed these few oddities while playing with some new NUMA
policies and attempted (badly) to at least fix the fact 'balancing' is
not shown in /proc/<pid>/numa_maps if selected via set_mempolicy/mbind.
So I also have a patch to allow 'balancing' to be parsed as tmpfs mount
option but did not post it yet. Now that Ying has uncovered problems in
this code go deeper we will see how this all develops.
Regards,
Tvrtko
next prev parent reply other threads:[~2024-06-28 9:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-25 13:26 Tvrtko Ursulin
2024-06-26 8:48 ` Huang, Ying
2024-06-26 11:51 ` Tvrtko Ursulin
2024-06-27 3:04 ` Huang, Ying
2024-06-27 21:37 ` Andrew Morton
2024-06-28 9:03 ` Tvrtko Ursulin [this message]
2024-06-27 21:47 ` Matthew Wilcox
2024-06-28 3:12 ` Huang, Ying
2024-06-28 8:56 ` Tvrtko Ursulin
2024-06-28 9:32 ` Huang, Ying
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=03641edd-3975-433e-a8d7-d79cb422dc57@igalia.com \
--to=tvrtko.ursulin@igalia.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=hannes@cmpxchg.org \
--cc=kernel-dev@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=rientjes@google.com \
--cc=tursulin@igalia.com \
--cc=willy@infradead.org \
--cc=ying.huang@intel.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