On Thu, Oct 7, 2021 at 9:37 AM Michal Hocko [off-list ref] wrote:

On Thu 07-10-21 08:45:21, Suren Baghdasaryan wrote:

quoted

On Thu, Oct 7, 2021 at 12:59 AM Michal Hocko [off-list ref] wrote:

quoted

On Wed 06-10-21 08:01:56, Suren Baghdasaryan wrote:

quoted

On Wed, Oct 6, 2021 at 2:27 AM David Hildenbrand [off-list ref] wrote:

quoted

On 06.10.21 10:27, Michal Hocko wrote:

quoted

On Tue 05-10-21 23:57:36, John Hubbard wrote:
[...]

quoted

1) Yes, just leave the strings in the kernel, that's simple and
it works, and the alternatives don't really help your case nearly
enough.

I do not have a strong opinion. Strings are easier to use but they
are more involved and the necessity of kref approach just underlines
that. There are going to be new allocations and that always can lead
to surprising side effects.  These are small (80B at maximum) so the
overall footpring shouldn't all that large by default but it can grow
quite large with a very high max_map_count. There are workloads which
really require the default to be set high (e.g. heavy mremap users). So
if anything all those should be __GFP_ACCOUNT and memcg accounted.

I do agree that numbers are just much more simpler from accounting,
performance and implementation POV.

+1

I can understand that having a string can be quite beneficial e.g., when
dumping mmaps. If only user space knows the id <-> string mapping, that
can be quite tricky.

However, I also do wonder if there would be a way to standardize/reserve
ids, such that a given id always corresponds to a specific user. If we
use an uint64_t for an id, there would be plenty room to reserve ids ...

I'd really prefer if we can avoid using strings and instead using ids.

I wish it was that simple and for some names like [anon:.bss] or
[anon:dalvik-zygote space] reserving a unique id would work, however
some names like [anon:dalvik-/system/framework/boot-core-icu4j.art]
are generated dynamically at runtime and include package name.
Packages are constantly evolving, new ones are developed, names can
change, etc. So assigning a unique id for these names is not really
feasible.

I still do not follow. If you need a globaly consistent naming then
you need clear rules for that, no matter whether that is number or a
file. How do you handle this with strings currently?

Some names represent standard categories, some are unique. A simple
tool could calculate and report the total for each name, a more
advanced tool might recognize some standard names and process them
differently. From kernel's POV, it's just a name used by the userspace
to categorize anonymous memory areas.

OK, so there is no real authority or any real naming convention. You
just hope that applications will behave so that the consumer of those
names can make proper calls. Correct?

In that case the same applies to numbers and I do not see any strong
argument for strings other than it is more pleasing to a human eye when
reading the file. And that doesn't sound like a strong argument to make
the kernel more complicated. Functionally both approaches are equal from
a practical POV.

I don't think that's correct. Names like [anon:.bss],
[anon:dalvik-zygote space] and
[anon:dalvik-/system/framework/boot-core-icu4j.art] provide user with
actionable information about the use of that memory or the allocator
using it. Names like [anon:1], [anon:2] and [anon:3] do not convey any
valuable information for the user until they are converted into
descriptive names.

--
Michal Hocko
SUSE Labs