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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 941A8C678D4 for ; Mon, 6 Mar 2023 07:51:47 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B12A6280001; Mon, 6 Mar 2023 02:51:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AC3346B0073; Mon, 6 Mar 2023 02:51:46 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98A5D280001; Mon, 6 Mar 2023 02:51:46 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8B9766B0072 for ; Mon, 6 Mar 2023 02:51:46 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5DC1740B7B for ; Mon, 6 Mar 2023 07:51:46 +0000 (UTC) X-FDA: 80537704212.03.4E8E1F4 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf20.hostedemail.com (Postfix) with ESMTP id 7AC301C0016 for ; Mon, 6 Mar 2023 07:51:43 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=LLPtpMVs; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678089103; a=rsa-sha256; cv=none; b=VSGoCKxzaSQJ0nwDgAF6oSUtvWpluxSsVGMv381lqSlDvCpCTLTcl5hfTdbUjdXZlWvJRD +zHk4AahW5Ilo8dbTxUU0KEcvfqEvwt5EaCxzFjfRAZbw1R4i4H/9/TFI0G7cq2ozcaEN/ XJVFsZ2gGQb6Rbqa0H3WAm2PhHP1/T0= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=LLPtpMVs; spf=pass (imf20.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678089103; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=S2m309QEoxNkbd3Zt8B9KYqe2aoELZppDrass+pnAeo=; b=JV5lu93DaFfyJXQMrR0Yq9T3zx94btoHdtG50Qnt2mmGUL7R888ri16oF0DHhPOKx66QEk jHhtE6s1W8rSlUukNCkgfBqEgZUIrB4Veh/RPHyv0yaCCbbxQmCcCBpgs13iFMSrMaPYZO 47G3XOM1NrW7vrqTq7ozO51XJ4GMjJo= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id D341D21D66; Mon, 6 Mar 2023 07:51:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1678089101; 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=S2m309QEoxNkbd3Zt8B9KYqe2aoELZppDrass+pnAeo=; b=LLPtpMVsajSSJ4yVb53aLeKTUMdZu/9uZTdN2XZv/62JSX4KVNR02Mnj8krSRXe8cC/pn7 LPclrsCaRv6kls6gxqiMNMRt3YSnvqPsr2GIxe/ZdOr8jmm5wHTm+nSMdLJj/Bmrnthl9l Oxi46gjcoM1SitnsC0KUY13BsJT3Ntk= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B46F313A66; Mon, 6 Mar 2023 07:51:41 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id yapeKY2bBWQeNAAAMHmgww (envelope-from ); Mon, 06 Mar 2023 07:51:41 +0000 Date: Mon, 6 Mar 2023 08:51:40 +0100 From: Michal Hocko To: Gao Xiang Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mel Gorman , Vlastimil Babka , Baoquan He , Christoph Hellwig , Uladzislau Rezki Subject: Re: [PATCH] mm/page_alloc: avoid high-order page allocation warn with __GFP_NOFAIL Message-ID: References: <20230305053035.1911-1-hsiangkao@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230305053035.1911-1-hsiangkao@linux.alibaba.com> X-Rspam-User: X-Rspamd-Queue-Id: 7AC301C0016 X-Rspamd-Server: rspam01 X-Stat-Signature: tf58ku1f8zturtayx7k8yy5r7xczftds X-HE-Tag: 1678089103-104662 X-HE-Meta: U2FsdGVkX18eOXRjs+TCvoHimDqZPSBkaqCh5uzYK6twjH5CCmSYJL/2iZqhjl4j3gGIv9WIJ1fFwROfh8GiKl262LRTebr8FEUIfp+FbknE3XJURWTdkaXlxytDWLHChAsKJClZkxH21G612ILi4qI5IycINtp5l85CliOvsJ1l8a6plK0LSKxa86fJprCwJdORC/Oy0EScxaNE5cxBE9V9AShdfEb9RlIxFWqGUns4PcX1WCmRWjQ9M2X0OxA/TACHUzaN4uwEWL6NK5Q9sVYAra+ZHB0nW6bg3UgZ2Q/wBDsNoPk0sGgExmhTe4aDgY1XpCXsHcQ1ot9+0hMf1oSWg3U2DleJqVGt7g1NhGP3TFV8BTZjGpamurTbGyOEKtMvRGONkBfZAmSfjZoqMeVeg6+3XQMzGkv1Qji6Q1rOdXkhUrT8Y1GkfG8gZn33xo/05AzGXkWAjAkYaztl6tj80BOAs9eXZmDpJVm7dyOaZM7xWXw5SGneJ+i6mMybjgg/ppMCPw6GDn90IH6yHvIVwsn7iMeZ4DVqjCkqjRNpJ1JU5mZQFab966sb6ns0AXICCceZmHFLiC+hjFA4HUNk+O+kMGT8Sx1vy3Fcdx1Hgoe9Dm683d+dJkLiOrRKMGfTJiXDEBkT8gcdMYq78evo0gh1uw6OTzbhHJDY6NEBVRtJ1JACMmeF/zXK+fimG0nW4WZkcdLk1dkoSACgOv5A1CCcwrlftuiiF3mg5MTsp+bZXARArFfnF63JI1img9CzuefKdy3ZemTt+Zr4d+wKfn4j1ul6ARr50L1E/mm5cEENNzyfesUSYYCw3Ewi/G6vhOvj/sFTOEFtP8tM6fitO+Q10vFQoaZ9c2GKoiAm0V63ZaR+JzF+e+TKopWmYG1SPwFtnX8f0XGglvO2oCu4ZqkZ9gHX6jggYLrhsZx9fUeFBf6oXPHxV48wSp6eNlAz4sEd53e3AFo3vPH sIGO4knE WbDvBYfp7a1JP7JkNtHwDwIFLj+lOnrHu0eWvQHsBAzkySDakmhJXA+p7FCe7cpmCmr9Q2q8bjHAE8nl5Y552Qc7qoQf7+ahdpRBZzYs0r1PVxo55ACCwgb8Oo2lMgZrOGw2yPFqjpQG1H0ENL8UnuPW27wAqRdIMY/U+P68irIL0DGdVN5H0xA5DOFchNNoBMp3uRAeNFHvO+hW/EmJzkPGlkSunEGLz80hYhM/YdYQKCqQKuYXNeVqDwljUXR80Az75W9KJ2x8BrLnw1cHZuRovZ2FcyDvui1dBnKfoTL1AQ/F6g/rJ9m2j5SHJkW2fMqaThxUwjIUquaM= 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: [Cc couple of more people recently involved with vmalloc code] On Sun 05-03-23 13:30:35, Gao Xiang wrote: > My knowledge of this is somewhat limited, however, since vmalloc already > supported __GFP_NOFAIL in commit 9376130c390a ("mm/vmalloc: add > support for __GFP_NOFAIL"). __GFP_NOFAIL could trigger the following > stack and allocate high-order pages when CONFIG_HAVE_ARCH_HUGE_VMALLOC > is enabled: > > __alloc_pages+0x1cb/0x5b0 mm/page_alloc.c:5549 > alloc_pages+0x1aa/0x270 mm/mempolicy.c:2286 > vm_area_alloc_pages mm/vmalloc.c:2989 [inline] > > __vmalloc_area_node mm/vmalloc.c:3057 [inline] > __vmalloc_node_range+0x978/0x13c0 mm/vmalloc.c:3227 > kvmalloc_node+0x156/0x1a0 mm/util.c:606 > kvmalloc include/linux/slab.h:737 [inline] > kvmalloc_array include/linux/slab.h:755 [inline] > kvcalloc include/linux/slab.h:760 [inline] > (codebase: Linux 6.2-rc2) > > Don't warn such cases since high-order pages with __GFP_NOFAIL is > somewhat legel. OK, this is definitely a bug and it seems my 9376130c390a was incomplete because it hasn't covered the high order case. Not sure how that happened but removing the warning is not the right thing to do here. The higher order allocation is an optimization rather than a must. So it is perfectly fine to fail that allocation and retry rather than go into a very expensive and potentially impossible higher order allocation that must not fail. The proper fix should look like this unless I am missing something. I would appreciate another pair of eyes on this because I am not fully familiar with the high order optimization part much. Thanks! --- diff --git a/mm/vmalloc.c b/mm/vmalloc.c index ef910bf349e1..a8aa2765618a 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -2883,6 +2883,8 @@ vm_area_alloc_pages(gfp_t gfp, int nid, unsigned int order, unsigned int nr_pages, struct page **pages) { unsigned int nr_allocated = 0; + gfp_t alloc_gfp = gfp; + bool nofail = false; struct page *page; int i; @@ -2931,20 +2933,30 @@ vm_area_alloc_pages(gfp_t gfp, int nid, if (nr != nr_pages_request) break; } + } else { + alloc_gfp &= ~__GFP_NOFAIL; + nofail = true; } /* High-order pages or fallback path if "bulk" fails. */ - while (nr_allocated < nr_pages) { if (fatal_signal_pending(current)) break; if (nid == NUMA_NO_NODE) - page = alloc_pages(gfp, order); + page = alloc_pages(alloc_gfp, order); else - page = alloc_pages_node(nid, gfp, order); - if (unlikely(!page)) - break; + page = alloc_pages_node(nid, alloc_gfp, order); + if (unlikely(!page)) { + if (!nofail) + break; + + /* fall back to the zero order allocations */ + alloc_gfp |= __GFP_NOFAIL; + order = 0; + continue; + } + /* * Higher order allocations must be able to be treated as * indepdenent small pages by callers (as they can with -- Michal Hocko SUSE Labs