On Wed, Jan 11, 2023 at 9:37 AM Michal Hocko [off-list ref] wrote:

On Wed 11-01-23 09:04:41, Suren Baghdasaryan wrote:

quoted

On Wed, Jan 11, 2023 at 8:44 AM Michal Hocko [off-list ref] wrote:

quoted

On Wed 11-01-23 08:28:49, Suren Baghdasaryan wrote:
[...]

quoted

Anyhow. Sounds like the overhead of the current design is small enough
to remove CONFIG_PER_VMA_LOCK and let it depend only on architecture
support?

Yes. Further optimizations can be done on top. Let's not over optimize
at this stage.

Sure, I won't optimize any further.
Just to expand on your question. Original design would be problematic
for embedded systems like Android. It notoriously has a high number of
VMAs due to anonymous VMAs being named, which prevents them from
merging.

What is the usual number of VMAs in that environment?

I've seen some games which had over 4000 VMAs but that's on the upper
side. In my calculations I used 40000 VMAs as a ballpark number and
rough calculations before size optimization would increase memory
consumption by ~2M (depending on the lock placement in vm_area_struct
it would vary a bit). In Android, the performance team flags any
change that exceeds 500KB, so it would raise questions.

--
Michal Hocko
SUSE Labs