On Fri, Jun 21, 2019 at 06:04:14PM +0000, Song Liu wrote: > > > > On Jun 21, 2019, at 9:30 AM, Song Liu <songliubrav...@fb.com> wrote: > > > > > > > >> On Jun 21, 2019, at 6:45 AM, Song Liu <songliubrav...@fb.com> wrote: > >> > >> > >> > >>> On Jun 21, 2019, at 6:36 AM, Kirill A. Shutemov <kir...@shutemov.name> > >>> wrote: > >>> > >>> On Fri, Jun 21, 2019 at 01:17:05PM +0000, Song Liu wrote: > >>>> > >>>> > >>>>> On Jun 21, 2019, at 5:48 AM, Kirill A. Shutemov <kir...@shutemov.name> > >>>>> wrote: > >>>>> > >>>>> On Thu, Jun 13, 2019 at 10:57:47AM -0700, Song Liu wrote: > >>>>>> After all uprobes are removed from the huge page (with PTE pgtable), it > >>>>>> is possible to collapse the pmd and benefit from THP again. This patch > >>>>>> does the collapse. > >>>>>> > >>>>>> An issue on earlier version was discovered by kbuild test robot. > >>>>>> > >>>>>> Reported-by: kbuild test robot <l...@intel.com> > >>>>>> Signed-off-by: Song Liu <songliubrav...@fb.com> > >>>>>> --- > >>>>>> include/linux/huge_mm.h | 7 +++++ > >>>>>> kernel/events/uprobes.c | 5 ++- > >>>>>> mm/huge_memory.c | 69 +++++++++++++++++++++++++++++++++++++++++ > >>>>> > >>>>> I still sync it's duplication of khugepaged functinallity. We need to > >>>>> fix > >>>>> khugepaged to handle SCAN_PAGE_COMPOUND and probably refactor the code > >>>>> to > >>>>> be able to call for collapse of particular range if we have all locks > >>>>> taken (as we do in uprobe case). > >>>>> > >>>> > >>>> I see the point now. I misunderstood it for a while. > >>>> > >>>> If we add this to khugepaged, it will have some conflicts with my other > >>>> patchset. How about we move the functionality to khugepaged after these > >>>> two sets get in? > >>> > >>> Is the last patch of the patchset essential? I think this part can be done > >>> a bit later in a proper way, no? > >> > >> Technically, we need this patch to regroup pmd mapped page, and thus get > >> the performance benefit after the uprobe is detached. > >> > >> On the other hand, if we get the first 4 patches of the this set and the > >> other set in soonish. I will work on improving this patch right after > >> that.. > > > > Actually, it might be pretty easy. We can just call try_collapse_huge_pmd() > > in khugepaged.c (in khugepaged_scan_shmem() or khugepaged_scan_file() after > > my other set). > > > > Let me fold that in and send v5. > > On a second thought, if we would have khugepaged to do collapse, we need a > dedicated bit to tell khugepaged which pmd to collapse. Otherwise, it may > accidentally collapse pmd that are split by other split_huge_pmd.
Why is it a problem? Do you know a situation where such collapse possible and will break split_huge_pmd() user's expectation. If there's such user it is broken: normal locking should prevent such situation. -- Kirill A. Shutemov
