答复: [PATCH] mm: Add RWH_RMAP_EXCLUDE flag to exclude files from rmap sharing

[Yibin Liu <liuyibin@hygon.cn>]

First of all, I am truly sorry for not using RFC.
Secondly, I omitted many maintainers because I wanted to “not disturb too many people”, 
and I apologize deeply for that. I will fully follow these two rules from now on.

As for this patch, indeed, as Matthew said, the truncate part is not feasible. 
My original intention was to apply this to frequently used library files like libc and ld.
Contention on the i_mmap_rwsem lock (which eventually turns into osq_lock) caused by
these two files alone reaches up to 70% in the “256-core execl” case, as observed from
flame graphs. Besides, no one performs truncate operations on libc and ld anyway.

So I wanted to try skipping rmap for them. Since they are small, even if they cannot
be reclaimed or migrated, I assumed it would not cause much trouble. Of course,
this idea was totally wrong, and I will definitely mark such insane proposals with RFC in the future.

These ideas are inspired by Mateusz’s work and thoughts
(https://lore.kernel.org/linux-mm/CAGudoHEfiOPJ2VGEV3fDT9cDsuoHB-wk8jg-k-EK6JhWgiHkWw@mail.gmail.com/),
so I specifically CC’d him to seek more opinions and insights.

Lastly, I sincerely apologize for the trouble I have caused the community.
I will strictly follow community conventions when sending patches in the future.

> NAK obviously.
> 
> I hate to keep saying this to people, but you've got no excuse at this stage
> it's been a year or so since we added mm maintainers/reviewers and you're not
> sending this to the right people.
> 
> How hard is doing:
> 
> $ scripts/get_maintainer.pl --no-git fs/fcntl.c fs/open.c include/linux/fs.h \
> 	include/uapi/linux/fcntl.h mm/mmap.c mm/vma.c
> Jeff Layton <jlayton@kernel.org> (maintainer:FILE LOCKING (flock() and
> fcntl()/lockf()))
> Chuck Lever <chuck.lever@oracle.com> (maintainer:FILE LOCKING (flock() and
> fcntl()/lockf()))
> Alexander Aring <alex.aring@gmail.com> (reviewer:FILE LOCKING (flock() and
> fcntl()/lockf()))
> Alexander Viro <viro@zeniv.linux.org.uk> (maintainer:FILESYSTEMS (VFS and
> infrastructure))
> Christian Brauner <brauner@kernel.org> (maintainer:FILESYSTEMS (VFS and
> infrastructure))
> Jan Kara <jack@suse.cz> (reviewer:FILESYSTEMS (VFS and infrastructure))
> Andrew Morton <akpm@linux-foundation.org> (maintainer:MEMORY
> MAPPING)
> "Liam R. Howlett" <Liam.Howlett@oracle.com> (maintainer:MEMORY
> MAPPING)
> Lorenzo Stoakes <ljs@kernel.org> (maintainer:MEMORY MAPPING)
> Vlastimil Babka <vbabka@kernel.org> (reviewer:MEMORY MAPPING)
> Jann Horn <jannh@google.com> (reviewer:MEMORY MAPPING)
> Pedro Falcato <pfalcato@suse.de> (reviewer:MEMORY MAPPING)
> linux-fsdevel@vger.kernel.org (open list:FILE LOCKING (flock() and fcntl()/lockf()))
> linux-kernel@vger.kernel.org (open list)
> linux-mm@kvack.org (open list:MEMORY MAPPING)
> 
> ?
> 
> You're sending an insane patch that breaks core mm and you can't even send it
> to
> the right people...
> 
> (And yet Mateusz is somehow cc'd (he loves that :))
> 
> This kind of craziness should be an RFC also as David said.
> 
> Both of these things are just rude and not helpful wrt upstream.
> ... ...
> ... ...
> This idea is totally broken.
> 
> If you want to contribute usefully, PLEASE drop this silly idea, come back with
> some NUMBERS about the contention you see, and let's have a sensible
> discussion
> about what we can do to address that?
> 
> Also follow standard upstream kernel procedures - figure out who to email
> properly, RFC insane ideas, etc.
> 
> Thanks, Lorenzo