Messages in this thread | | | From | Song Liu <> | Subject | Re: [PATCH v4 5/5] uprobe: collapse THP pmd after removing all uprobes | Date | Mon, 24 Jun 2019 13:53:02 +0000 |
| |
> On Jun 24, 2019, at 5:34 AM, Kirill A. Shutemov <kirill@shutemov.name> wrote: > > On Fri, Jun 21, 2019 at 06:04:14PM +0000, Song Liu wrote: >> >> >>> On Jun 21, 2019, at 9:30 AM, Song Liu <songliubraving@fb.com> wrote: >>> >>> >>> >>>> On Jun 21, 2019, at 6:45 AM, Song Liu <songliubraving@fb.com> wrote: >>>> >>>> >>>> >>>>> On Jun 21, 2019, at 6:36 AM, Kirill A. Shutemov <kirill@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 <kirill@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 <lkp@intel.com> >>>>>>>> Signed-off-by: Song Liu <songliubraving@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. >
You are right. I found the the same after a third thought. So I tried to get that logic in v6.
Thanks, Song
| |