lkml.org 
[lkml]   [2021]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC PATCH 7/8] hugetlb: add update_and_free_page_no_sleep for irq context
    On Mon, Mar 22, 2021 at 10:42:23AM -0700, Mike Kravetz wrote:
    > Cc: Roman, Christoph
    >
    > On 3/22/21 1:41 AM, Peter Zijlstra wrote:
    > > On Fri, Mar 19, 2021 at 03:42:08PM -0700, Mike Kravetz wrote:
    > >> The locks acquired in free_huge_page are irq safe. However, in certain
    > >> circumstances the routine update_and_free_page could sleep. Since
    > >> free_huge_page can be called from any context, it can not sleep.
    > >>
    > >> Use a waitqueue to defer freeing of pages if the operation may sleep. A
    > >> new routine update_and_free_page_no_sleep provides this functionality
    > >> and is only called from free_huge_page.
    > >>
    > >> Note that any 'pages' sent to the workqueue for deferred freeing have
    > >> already been removed from the hugetlb subsystem. What is actually
    > >> deferred is returning those base pages to the low level allocator.
    > >
    > > So maybe I'm stupid, but why do you need that work in hugetlb? Afaict it
    > > should be in cma_release().
    >
    > My thinking (which could be totally wrong) is that cma_release makes no
    > claims about calling context. From the code, it is pretty clear that it
    > can only be called from task context with no locks held. Although,
    > there could be code incorrectly calling it today hugetlb does. Since
    > hugetlb is the only code with this new requirement, it should do the
    > work.
    >
    > Wait!!! That made me remember something.
    > Roman had code to create a non-blocking version of cma_release().
    > https://lore.kernel.org/linux-mm/20201022225308.2927890-1-guro@fb.com/
    >
    > There were no objections, and Christoph even thought there may be
    > problems with callers of dma_free_contiguous.
    >
    > Perhaps, we should just move forward with Roman's patches to create
    > cma_release_nowait() and avoid this workqueue stuff?

    Sounds good to me. If it's the preferred path, I can rebase and resend
    those patches (they been carried for some time by Zi Yan for his 1GB THP work,
    but they are completely independent).

    Thanks!


    > --
    > Mike Kravetz

    \
     
     \ /
      Last update: 2021-03-22 19:13    [W:5.487 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site