lkml.org 
[lkml]   [2021]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 6/9] mm: free user PTE page table pages
    From
    Date


    On 2021/9/2 AM1:55, Jason Gunthorpe wrote:
    > On Wed, Sep 01, 2021 at 07:49:23PM +0200, David Hildenbrand wrote:
    >> On 01.09.21 19:10, Jason Gunthorpe wrote:
    >>> On Wed, Sep 01, 2021 at 06:19:03PM +0200, David Hildenbrand wrote:
    >>>
    >>>>> I wouldn't think it works everywhere, bit it works in a lot of places,
    >>>>> and it is a heck of a lot better than what is proposed here. I'd
    >>>>> rather see the places that can use it be moved, and the few places
    >>>>> that can't be opencoded.
    >>>>
    >>>> Well, I used ptep_get_map_lock() and friends. But hacking directly into
    >>>> ptep_map_lock() and friends wasn't possible due to all the corner cases.
    >>>
    >>> Sure, I'm not surprised you can't get every single case, but that just
    >>> suggest we need two API families, today's to support the special cases
    >>> and a different one for the other regular simple cases.
    >>>
    >>> A new function family pte_try_map/_locked() and paired unmap that can
    >>> internally do the recounting and THP trickery and convert the easy
    >>> callsites.
    >>>
    >>> Very rough counting suggest at least half of the pte_offset_map_lock()
    >>> call sites can trivially use the simpler API.
    >>>
    >>> The other cases can stay as is and get open coded refcounts, or maybe
    >>> someone will have a better idea once they are more clearly identified.
    >>>
    >>> But I don't think we should take a performance hit of additional
    >>> atomics in cases like GUP where this is trivially delt with by using a
    >>> better API.
    >>
    >> Right, but as I said in the cover letter, we can happily optimize once we
    >> have the basic infrastructure in place and properly reviewed. Getting rid of
    >> some unnecessary atomics by introducing additional fancy helpers falls under
    >> that category.
    >
    > I'm not sure I agree given how big and wide this patch series is. It
    > would be easier to review if it was touching less places. The helpers
    > are not fancy, it is a logical re-arrangement of existing code that
    > shrinks the LOC of this series and makes it more reviewable.
    >
    > Or stated another way, a niche feature like this try much harder not
    > to add more complexity everywhere.

    Totally agree, I will rework this patch series based on you and David's
    suggestions.

    Thank you very much,
    Qi

    >
    > Jason
    >

    \
     
     \ /
      Last update: 2021-09-02 09:06    [W:2.303 / U:0.240 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site