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 D993DC433E0 for ; Thu, 18 Feb 2021 08:21:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5995C64E68 for ; Thu, 18 Feb 2021 08:21:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5995C64E68 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 ACEC16B006E; Thu, 18 Feb 2021 03:21:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A7FBE6B0070; Thu, 18 Feb 2021 03:21:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 96DE86B0071; Thu, 18 Feb 2021 03:21:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0044.hostedemail.com [216.40.44.44]) by kanga.kvack.org (Postfix) with ESMTP id 8095F6B006E for ; Thu, 18 Feb 2021 03:21:37 -0500 (EST) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3F927181AF5C4 for ; Thu, 18 Feb 2021 08:21:37 +0000 (UTC) X-FDA: 77830694634.11.stone38_3505ca327653 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id 1BE88180F8B80 for ; Thu, 18 Feb 2021 08:21:37 +0000 (UTC) X-HE-Tag: stone38_3505ca327653 X-Filterd-Recvd-Size: 4513 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Thu, 18 Feb 2021 08:21:36 +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=1613636495; 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=Iy07AOSgNqm+R91SC7oREQlpbXz4qmRIVGZCrE6AhuY=; b=ExfopU0B8BLib5q2xKI/qzE1ZkLkoWTD+4+HXnhga/CtFgYKnD2gf2so3fkfp09ilqNHrL 5SyVNbfeNbiEqeFxLV5tylw3Gm2F8zeMVaDF/44uq4kFZxea1Kc3lYkfQz6kKsgi/rsL8o Nf5I1WEP01gCovDHsswXFOx3/8XyyIc= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id E45B3AFC1; Thu, 18 Feb 2021 08:21:34 +0000 (UTC) Date: Thu, 18 Feb 2021 09:21:31 +0100 From: Michal Hocko To: Muchun Song Cc: Mike Kravetz , Jonathan Corbet , Thomas Gleixner , mingo@redhat.com, bp@alien8.de, x86@kernel.org, hpa@zytor.com, dave.hansen@linux.intel.com, luto@kernel.org, Peter Zijlstra , viro@zeniv.linux.org.uk, Andrew Morton , paulmck@kernel.org, mchehab+huawei@kernel.org, pawan.kumar.gupta@linux.intel.com, Randy Dunlap , oneukum@suse.com, anshuman.khandual@arm.com, jroedel@suse.de, Mina Almasry , David Rientjes , Matthew Wilcox , Oscar Salvador , "Song Bao Hua (Barry Song)" , David Hildenbrand , HORIGUCHI =?utf-8?B?TkFPWUEo5aCA5Y+jIOebtOS5nyk=?= , Joao Martins , Xiongchun duan , linux-doc@vger.kernel.org, LKML , Linux Memory Management List , linux-fsdevel Subject: Re: [External] Re: [PATCH v15 4/8] mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page Message-ID: References: <29cdbd0f-dbc2-1a72-15b7-55f81000fa9e@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thu 18-02-21 11:20:51, Muchun Song wrote: > On Thu, Feb 18, 2021 at 9:00 AM Mike Kravetz wrote: > > > > On 2/17/21 12:13 AM, Michal Hocko wrote: > > > On Tue 16-02-21 11:44:34, Mike Kravetz wrote: > > > [...] > > >> If we are not going to do the allocations under the lock, then we will need > > >> to either preallocate or take the workqueue approach. > > > > > > We can still drop the lock temporarily right? As we already do before > > > calling destroy_compound_gigantic_page... > > > > > > > Yes we can. I forgot about that. > > > > Actually, very little of what update_and_free_page does needs to be done > > under the lock. Perhaps, just decrementing the global count and clearing > > the destructor so PageHuge() is no longer true. > > Right. I have another question about using GFP flags. Michal > suggested using GFP_KERNEL instead of GFP_ATOMIC to > save reserve memory. From your last email, you suggested > using non-blocking allocation GFP flags (perhaps GFP_NOWAIT). > > Hi Mike and Michal, > > What is the consensus we finally reached? Thanks. If the lock can be dropped and you make sure the final put on page is not called from an atomic context then use (for starter) GFP_KERNEL | __GFP_NORETRY | __GFP_THISNODE. I have intentionaly dropped __GFP_NOWARN because likely want to hear about the failure so that we can evaluate how often this happens. This would be my recommendation. -- Michal Hocko SUSE Labs