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=-1.0 required=3.0 tests=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 6F84BC3F2C6 for ; Tue, 10 Mar 2020 17:37:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3B99420675 for ; Tue, 10 Mar 2020 17:37:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B99420675 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D26D56B0005; Tue, 10 Mar 2020 13:37:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CD7136B0006; Tue, 10 Mar 2020 13:37:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC5D86B0007; Tue, 10 Mar 2020 13:37:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0105.hostedemail.com [216.40.44.105]) by kanga.kvack.org (Postfix) with ESMTP id A050B6B0005 for ; Tue, 10 Mar 2020 13:37:43 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 60C6110EFA for ; Tue, 10 Mar 2020 17:37:43 +0000 (UTC) X-FDA: 76580160006.08.talk97_7d877f13e3c05 X-HE-Tag: talk97_7d877f13e3c05 X-Filterd-Recvd-Size: 4313 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Mar 2020 17:37:42 +0000 (UTC) Received: by mail-wm1-f65.google.com with SMTP id 11so2048618wmo.2 for ; Tue, 10 Mar 2020 10:37:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=jugY1Nf3CufQZkDFT05apdS40zYN+FeXe0bfIW9g3ro=; b=JXomrzv8BYNXHkF8Sn/nIDfca8AkB2wYFXlbPZZdQ+ZosIQRCEIpoFrfhTLSPFlGg7 6PIDNnzglLx1TWebxYBPRzfXdg314ZIw/EdXxGOhL8QYaTnOh+jeKH03hrk5GTrTJtki rsc+yqVzY5PQLEX/C4eeIfVv2UfwQRCBp7ou0TaF90ToJoV/XFUZXDai51PtAFcOyId2 SlwMXaS52ppPoW6XdZqO0nKuujAGzkzCOTJ52REAmUazQDsTltcFlUd2nr4yGnZXe+G2 yZeymolKRz89C1+kkghBoIfiutBQauD6v1d6s1tk3XTMETPfnqlmtTJvKSM3c4jqpgEL tH5A== X-Gm-Message-State: ANhLgQ2ua7QExjyFHr6sb+SRcxzRCgrJSBTg9QShoa/AMSRQv27BRsZS J+EDyNk/1V8F415jl9gOqds= X-Google-Smtp-Source: ADFU+vvZ2CQS4ziwKXm0n/KU6Q4DJKoDwZEqBReNJdls11/tAY8wRDLKYKcwxqmow79W57+WuhldhQ== X-Received: by 2002:a05:600c:2:: with SMTP id g2mr3129868wmc.18.1583861861293; Tue, 10 Mar 2020 10:37:41 -0700 (PDT) Received: from localhost (ip-37-188-253-35.eurotel.cz. [37.188.253.35]) by smtp.gmail.com with ESMTPSA id q1sm25472778wrx.19.2020.03.10.10.37.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2020 10:37:40 -0700 (PDT) Date: Tue, 10 Mar 2020 18:37:38 +0100 From: Michal Hocko To: Roman Gushchin Cc: Andrew Morton , Johannes Weiner , linux-mm@kvack.org, kernel-team@fb.com, linux-kernel@vger.kernel.org, Rik van Riel , Mike Kravetz Subject: Re: [PATCH v2] mm: hugetlb: optionally allocate gigantic hugepages using cma Message-ID: <20200310173738.GW8447@dhcp22.suse.cz> References: <20200310002524.2291595-1-guro@fb.com> <20200310084544.GY8447@dhcp22.suse.cz> <20200310172559.GA85000@carbon.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200310172559.GA85000@carbon.dhcp.thefacebook.com> 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 10-03-20 10:25:59, Roman Gushchin wrote: > Hello, Michal! > > On Tue, Mar 10, 2020 at 09:45:44AM +0100, Michal Hocko wrote: [...] > > > + for_each_node_state(nid, N_ONLINE) { > > > + unsigned long min_pfn = 0, max_pfn = 0; > > > + > > > + for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) { > > > + if (!min_pfn) > > > + min_pfn = start_pfn; > > > + max_pfn = end_pfn; > > > + } > > > > Do you want to compare the range to the size? > > You mean add a check that the range is big enough? Yes, size and forgot to mention alignment. > > But besides that, I > > believe this really needs to be much more careful. I believe you do not > > want to eat a considerable part of the kernel memory because the > > resulting configuration will really struggle (yeah all the low mem/high > > mem problems all over again). > > Well, so far I was focused on a particular case when the target cma size > is significantly smaller than the total RAM size (~5-10%). What is the right > thing to do here? Fallback to the current behavior if the requested size is > more than x% of total memory? 1/2? How do you think? I would start by excluding restricted kernel zones ( We've discussed it with Rik in private, and he expressed an idea to start > with ~50% always and then shrink it on-demand. Something that we might > have here long-term. I would start simple. Simply make it a documented behavior. And if somebody really cares enough then we can make something more clever. Until then just avoid zone as mentioned above. This would require that you do few changes 1) allow fallback from CMA allocation failure 2) do not bail out initialization on CMA reservation failure. -- Michal Hocko SUSE Labs