Re: [PATCH v11 2/3] mm: add a field to store names for private anonymous memory

[Suren Baghdasaryan]

On Tue, Nov 16, 2021 at 1:51 AM Michal Hocko <mhocko@xxxxxxxx> wrote:
>
> On Mon 15-11-21 10:59:20, Suren Baghdasaryan wrote:
> [...]
> > Hi Andrew,
> > I haven't seen any feedback on my patchset for some time now. I think
> > I addressed all the questions and comments (please correct me if I
> > missed anything).
>
> I believe the strings vs. ids have been mostly hand waved away. The
> biggest argument for the former was convenience for developers to have
> something human readable. There was no actual proposal about the naming
> convention so we are relying on some unwritten rules or knowledge of the
> code to be debugged to make human readable string human understandable
> ones. I believe this has never been properly resolved except for - this
> has been used in Android and working just fine. I am not convinced TBH.
>
> So in the end we are adding a user interface that brings a runtime and
> resource overhead that will be hard to change in the future. Reference
> counting handles a part of that and that is nice but ids simply do not
> have any of that.

I explained the way this interface is used and why ids would not work
for us in https://lore.kernel.org/all/CAJuCfpESeM_Xd8dhCj_okNggtDUXx3Nn9FpL_f9qsKXKZzCKpA@xxxxxxxxxxxxxx.
I explored all the proposed alternatives, all of which would be
prohibitive for our needs due to performance costs compared to this
solution. I wish I could come up with something simpler but a simpler
solution simply does not meet our needs.

It's true that this approach does not formalize how VMAs are named but
I don't see why kernel should impose a naming convention. I can see
some systems defining more formal conventions but I believe it should
be up to the userspace to do that.

>
> > Can it be accepted as is or is there something I should address
> > further?
>
> Is the above reason to nack it? No, I do not think so. I just do not
> feel like I want to ack it either. Concerns have been expressed and I
> have to say that I would like a minimalistic approach much more. Also
> extending ids into string is always possible. The other way around is
> not possible.

Unfortunately, extending ids into strings comes with the cost we can't
afford in Android. Therefore I don't see a point for me to upstream
such a solution which I can't use.
Thanks,
Suren.

>
> --
> Michal Hocko
> SUSE Labs