On 10/21/24 9:32 AM, Suren Baghdasaryan wrote:
On Mon, Oct 21, 2024 at 9:23 AM Michal Hocko <mhocko@xxxxxxxx> wrote:
On Mon 21-10-24 09:16:14, Suren Baghdasaryan wrote:
On Mon, Oct 21, 2024 at 8:57 AM Michal Hocko <mhocko@xxxxxxxx> wrote:
On Mon 21-10-24 08:41:00, Suren Baghdasaryan wrote:
On Mon, Oct 21, 2024 at 8:34 AM Michal Hocko <mhocko@xxxxxxxx> wrote:
On Mon 21-10-24 08:05:16, Suren Baghdasaryan wrote:
[...]
Yeah, I thought about adding new values to "mem_profiling" but it's a
bit complicated. Today it's a tristate:
mem_profiling=0|1|never
0/1 means we disable/enable memory profiling by default but the user
can enable it at runtime using a sysctl. This means that we enable
page_ext at boot even when it's set to 0.
"never" means we do not enable page_ext, memory profiling is disabled
and sysctl to enable it will not be exposed. Used when a distribution
has CONFIG_MEM_ALLOC_PROFILING=y but the user does not use it and does
not want to waste memory on enabling page_ext.
I can add another option like "pgflags" but then it also needs to
specify whether we should enable or disable profiling by default
(similar to 0|1 for page_ext mode). IOW we will need to encode also
the default state we want. Something like this:
mem_profiling=0|1|never|pgflags_on|pgflags_off
Would this be acceptable?
Isn't this overcomplicating it? Why cannot you simply go with
mem_profiling={0|never|1}[,$YOUR_OPTIONS]
While $YOUR_OPTIONS could be compress,fallback,ponies and it would apply
or just be ignored if that is not applicable.
Oh, you mean having 2 parts in the parameter with supported options being:
mem_profiling=never
mem_profiling=0
mem_profiling=1
mem_profiling=0,pgflags
mem_profiling=1,pgflags
Did I understand correctly? If so then yes, this should work.
yes. I would just not call it pgflags because that just doesn't really
tell what the option is to anybody but kernel developers. You could also
have an option to override the default (disable profiling) failure strategy.
Ok, how about "compressed" instead? Like this:
mem_profiling=0,compressed
Yes. The configuration options all fit together nicely now, and the
naming seems exactly right as well. And no more "you must rebuild your
kernel" messages. Great!
thanks,
--
John Hubbard
Sounds good to me. And just to repeat, I do not really care about
specific name but let's just stay away from something as specific as
page flags because that is really not helping to understand the purpose
but rather the underlying mechanism which is not telling much to most
users outside of kernel developers.
Understood. Ok, I'll start changing my patchset to incorporate this
feedback and will post the new version this week.
Thanks for the input everyone!
--
Michal Hocko
SUSE Labs
