Re: [PATCH v11 2/3] mm: add a field to store names for private anonymous memory
From: Suren Baghdasaryan <surenb@google.com>
Date: 2021-11-16 16:29:24
Also in:
linux-doc, linux-fsdevel, lkml
On Tue, Nov 16, 2021 at 1:51 AM Michal Hocko [off-list ref] wrote:
On Mon 15-11-21 10:59:20, Suren Baghdasaryan wrote: [...]quoted
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@mail.gmail.com (local). 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.
quoted
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