> On Jun 21, 2019, at 6:45 AM, Song Liu <songliubraving@xxxxxx> wrote: > > > >> On Jun 21, 2019, at 6:36 AM, Kirill A. Shutemov <kirill@xxxxxxxxxxxxx> 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 <kirill@xxxxxxxxxxxxx> 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 <lkp@xxxxxxxxx> >>>>> Signed-off-by: Song Liu <songliubraving@xxxxxx> >>>>> --- >>>>> 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. Thanks, Song
