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
