[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2383057a-29dc-383b-720f-7cdcdd015e40@oracle.com>
Date: Mon, 22 Mar 2021 10:42:23 -0700
From: Mike Kravetz <mike.kravetz@...cle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Michal Hocko <mhocko@...e.com>,
Shakeel Butt <shakeelb@...gle.com>,
Oscar Salvador <osalvador@...e.de>,
David Hildenbrand <david@...hat.com>,
Muchun Song <songmuchun@...edance.com>,
David Rientjes <rientjes@...gle.com>,
Miaohe Lin <linmiaohe@...wei.com>,
Matthew Wilcox <willy@...radead.org>,
HORIGUCHI NAOYA <naoya.horiguchi@....com>,
"Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>,
Waiman Long <longman@...hat.com>, Peter Xu <peterx@...hat.com>,
Mina Almasry <almasrymina@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Roman Gushchin <guro@...com>,
Christoph Hellwig <hch@...radead.org>
Subject: Re: [RFC PATCH 7/8] hugetlb: add update_and_free_page_no_sleep for
irq context
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?
--
Mike Kravetz
Powered by blists - more mailing lists