From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D44B0C433DB for ; Wed, 24 Mar 2021 08:43:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6780E619F6 for ; Wed, 24 Mar 2021 08:43:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 6780E619F6 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EC8896B0289; Wed, 24 Mar 2021 04:43:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E789C6B028D; Wed, 24 Mar 2021 04:43:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D19476B0292; Wed, 24 Mar 2021 04:43:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0186.hostedemail.com [216.40.44.186]) by kanga.kvack.org (Postfix) with ESMTP id B8B0B6B0289 for ; Wed, 24 Mar 2021 04:43:40 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 66E9A9987 for ; Wed, 24 Mar 2021 08:43:40 +0000 (UTC) X-FDA: 77954129400.33.0E4888B Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf09.hostedemail.com (Postfix) with ESMTP id 1DE7A6000101 for ; Wed, 24 Mar 2021 08:43:39 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1616575418; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Cnv9o+YxLuD1qTXpONvaw+ySFYu0LbsCuQMUfJJE1Cg=; b=Ret7YQUa5IX1n2tf18nAekK9Ytlnb01tMiYfFXmVQ5o/MepwPrvX6QLPn7KTFZGHuWb0m9 oVkdD967+yLGE4J0D7XuGrxuywONddWngf50BUocjllnA92+uczBQcTn/clWMDxHLtfr8H AA9xojLofYGWNQp8WeiyBMHRMiYVe4k= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id AC1ADAB9B; Wed, 24 Mar 2021 08:43:38 +0000 (UTC) Date: Wed, 24 Mar 2021 09:43:35 +0100 From: Michal Hocko To: Mike Kravetz Cc: Roman Gushchin , Peter Zijlstra , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Shakeel Butt , Oscar Salvador , David Hildenbrand , Muchun Song , David Rientjes , Miaohe Lin , Matthew Wilcox , HORIGUCHI NAOYA , "Aneesh Kumar K . V" , Waiman Long , Peter Xu , Mina Almasry , Andrew Morton , Christoph Hellwig Subject: Re: [RFC PATCH 7/8] hugetlb: add update_and_free_page_no_sleep for irq context Message-ID: References: <20210319224209.150047-1-mike.kravetz@oracle.com> <20210319224209.150047-8-mike.kravetz@oracle.com> <2383057a-29dc-383b-720f-7cdcdd015e40@oracle.com> <8a28c691-1e7c-1463-9d59-da31a2926adc@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a28c691-1e7c-1463-9d59-da31a2926adc@oracle.com> X-Stat-Signature: q83hzds6pyex1y8dgyusxya8qnz8e7no X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 1DE7A6000101 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf09; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1616575419-404714 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue 23-03-21 11:51:04, Mike Kravetz wrote: > On 3/22/21 11:10 AM, Roman Gushchin wrote: > > 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 Roman, > > Yes, this is the preferred path. If there is a non blocking version of > cma_release, then it makes fixup of hugetlb put_page path much easier. I do not object to the plan I just want to point out that the sparse vmemmap for hugetlb pages will need to recognize sleep/nosleep variants of the freeing path as well to handle its vmemmap repopulate games. -- Michal Hocko SUSE Labs