Re: [PATCH v4 5/5] uprobe: collapse THP pmd after removing all uprobes

[Song Liu]

> 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..

Thanks,
Song