On Sat, Sep 18, 2021 at 10:51 PM Muchun Song <songmuchun@xxxxxxxxxxxxx> wrote: > > On Sat, Sep 18, 2021 at 1:07 PM Barry Song <21cnbao@xxxxxxxxx> wrote: > > > > On Sat, Sep 18, 2021 at 12:09 AM Muchun Song <songmuchun@xxxxxxxxxxxxx> wrote: > > > > > > The init_mm.page_table_lock is used to protect kernel page tables, we > > > can use it to serialize splitting vmemmap PMD mappings instead of mmap > > > write lock, which can increase the concurrency of vmemmap_remap_free(). > > > > > > > Curious what is the actual benefit we get in user scenarios from this patch, > > 1. we set bootargs to reserve hugetlb statically > > 2. we "echo" some figures to sys or proc. > > > > In other words, Who is going to care about this concurrency? > > Actually, It increase the concurrency between allocations of > HugeTLB pages. But it is not my first consideration. There are > a lot of users of mmap read lock of init_mm. The mmap write > lock is holding through vmemmap_remap_free(), I want to make > it does not affect other users of mmap read lock. generically makes sense. I guess it wouldn't be critical at all for hugetlb allocation as practically we are not going to reserve and release hugtlb often as they are not THP. anyway, it is not making anything worse and always a win to move. > > I suppose a lot of developers are trying to avoid using mmap write > lock. I am also one of them. > > > Can we have some details on this to put in the commit log? > > For sure. Those judgments above should be placed in the > commit log. > > Thanks. Thanks barry
