From patchwork Mon Mar 6 14:03:10 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michal Hocko X-Patchwork-Id: 13161124 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 1248CC6FD1C for ; Mon, 6 Mar 2023 14:03:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6EFBD280002; Mon, 6 Mar 2023 09:03:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6A1BB280001; Mon, 6 Mar 2023 09:03:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5675D280002; Mon, 6 Mar 2023 09:03:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 47065280001 for ; Mon, 6 Mar 2023 09:03:17 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DFA3AC0A04 for ; Mon, 6 Mar 2023 14:03:16 +0000 (UTC) X-FDA: 80538640392.16.BF3783B Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf25.hostedemail.com (Postfix) with ESMTP id A35CEA0013 for ; Mon, 6 Mar 2023 14:03:13 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=p8VodS8j; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 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=1678111394; 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=TYnoqEXRVg+qMdr+nCTEH9NvoiErpUcpOCA1haXbDNw=; b=0WOQUuANniGv82ymOCbuZ7LvrV005Q2fcAEVaGlYUlWdpvYNptBHYwEUKckjAFyuzIzcj7 pjuHLGgtD/MHHcNU3P48toVy719ti85uRfbNrcgpJXAAnuQFeTgqCS1nDwrkC8BQ7T4yHo lBatiqRm2W2wEDr+A8DTNJ51FQK7Tdg= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=p8VodS8j; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 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=1678111394; a=rsa-sha256; cv=none; b=kop/z3onTW+5Ol+sqfTkIK3jpFFakHW359Nf10hM+l2I1f3X/6suWpKgxoDKxKvkvHYkRt H9CQOhRZukGYHqilKc5TI5DeteMo89nZggq2TN+3ssI+epbKLJORwff4I121CnRpxf+fdi p2eTVrtfhpQvec9w2La4azffSOQ/pHw= 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-out2.suse.de (Postfix) with ESMTPS id C068E1FDF9; Mon, 6 Mar 2023 14:03:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1678111391; 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=TYnoqEXRVg+qMdr+nCTEH9NvoiErpUcpOCA1haXbDNw=; b=p8VodS8jKgqg95OpLwdeeP4M0upBsUSA0EPLP3tQ5uRZAvppX0Q0fOMrlE/YIYoomrPyOr OU2aGTMvvGBvuSHIYkLqXbE4aV2Zgj1zpDJOKFBuh8jYlmfMdfTSd5hw8h5i2XLly6J73e +Kp/wfIvetaZ/0q2hEyS9ozZXCSQsz0= 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 A426F13513; Mon, 6 Mar 2023 14:03:11 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id h0Q2JZ/yBWSpdgAAMHmgww (envelope-from ); Mon, 06 Mar 2023 14:03:11 +0000 Date: Mon, 6 Mar 2023 15:03:10 +0100 From: Michal Hocko To: Uladzislau Rezki Cc: Gao Xiang , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mel Gorman , Vlastimil Babka , Baoquan He , Christoph Hellwig Subject: [PATCH] mm, vmalloc: fix high order __GFP_NOFAIL allocations Message-ID: References: <20230305053035.1911-1-hsiangkao@linux.alibaba.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-Stat-Signature: qtoskk3a9ekm1b5qzbqhagixhz5cqkg3 X-Rspam-User: X-Rspamd-Queue-Id: A35CEA0013 X-Rspamd-Server: rspam06 X-HE-Tag: 1678111393-760781 X-HE-Meta: U2FsdGVkX1/C9/MSXwt3McyBpfFUi2hrW0SG2TkJJWXMr1P+M51hRcXZr1rluY/fYUCfJ/6uRXJUO5rd+dLZZZ09CxNpUfe17YjhQnd0BHfKxjhZo52eS8x9ilLcsrihTesgB/0iArNp+rUGlmM0AU9TofBiyCU0K7OtdqB7TJAGhB8WfGhWgHMpbnR0Wi0kgg+vGBHg3O7es+qzncCCp4Z8i3JaqOasSUHqk1am+a4eeJxeuMPYqLEYg8q7E5gdUpreOAk1I0wjaZ0tjOCQXxoav2igjd5YeYFL9exP6lIiPYlYcAmrufsxHka98uaLR7nVcM3WlnayIkfw6iMEZv5LVuuFFtrQuYcXuIImNxK9rmFriPmyqeC7Z5iGj0IUdBKZu6yt8gLzjzJMJsJFzMdRX5Ka6sQQpiZDkU4g0SgAW7yjyOPBzxozMwS3dRh8sQ3SM86L1t8nZSDgvhiq9iVAeKUR2pEK+GzSke8odFZegea8eemoY17Y/5Bd0WjEqZRVnD58PRj2IFUUvqNLarNcDK60t2dOMsG/Z00W2IBqRdkQAwQrhqyhKwQYe6A81FJEPsfH5hUqAWra2+safBrv21vSEdXku/3xSg1VuNh3GwLLe13iVQgoGZ2mL5oU8z9DUl2KGrS7Beb8BVXeASey8PygrJe/Nvxn6nvDW+L+VC15unj66krwjvV2WIwkc+6n3NqOF2JuYqeCRAD755shpEf6UthV/6KKn03920P2pJzx2JAarZiBH9RY5f+ERBORKLt9BIy4fQw/9MZl408k5QaaSy3VO29zLmfNxJjE6EYTiGVrzumLfpA3czN5jRZuuwVi9ZPCBTlmdu0f/ve+rDJxixp7SO2nUUtYnBQzY+L5bZdKXfb8amS7nVs6TzSSAVuf4rY92HNqR1fjguQYK3ssHtbQaOe0iiCAQY6JpUkhU+7kgtEAxZNkwBAsN3x+MuIHZ1lF3rsvjmo YkZ4wmsg fozUEaYw8hKbIhHo3gBtG8WrfjmykOrG8P/UuGcFG+sPKGzBEBhA1pXz/38y3fwh22jk0G9HqgFn6n6yBpLgHhDT1i43/40LU5sULPEndzI0m/HvLzhXBQYdbn5pQ5HirJznM4U7PSZ2/5Tp4ghZG9C+yxEY7lBnNjbZgj1MyBuwmcoZkUK3vLkfiFFIzJ/Cpnn3EAAdTnrpxEz4T13G2FhlLs3B22Sw3ANScLaD0j25xBr/LtjDqrj9xJK+inC0iC+xMuJfe6Nx2FV2fAtKwLuUIJy4IvoHZTN6A3rBAFM9TIYSslF3sBzpzLS5kJRTToH7lv97j8wFOxhJa68LuyMMsW5OMGGMAo6yQuyOe3KEQf5e3aDkspUKHYz7LFtiG5G5kk75RSWDs5z9Woq9UJAFL2Dt9V37jtQKv 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 Mon 06-03-23 13:14:43, Uladzislau Rezki wrote: [...] > Some questions: > > 1. Could you please add a comment why you want the bulk_gfp without > the __GFP_NOFAIL(bulk path)? The bulk allocator is not documented to fully support __GFP_NOFAIL semantic IIRC. While it uses alloc_pages as fallback I didn't want to make any assumptions based on the current implementation. At least that is my recollection. If we do want to support NOFAIL by the batch allocator then we can drop the special casing here. > 2. Could you please add a comment why a high order pages do not want > __GFP_NOFAIL? You have already explained. See below > 3. Looking at the patch: > > > + } else { > + alloc_gfp &= ~__GFP_NOFAIL; > + nofail = true; > > > if user does not want to go with __GFP_NOFAIL flag why you force it in > case a high order allocation fails and you switch to 0 order allocations? Not intended. The above should have been else if (gfp & __GFP_NOFAIL). Thanks for catching that! This would be the full patch with the description: Reviewed-by: Uladzislau Rezki (Sony) Acked-by: Vlastimil Babka --- From 3ccfaa15bf2587b8998c129533a0404fedf5a484 Mon Sep 17 00:00:00 2001 From: Michal Hocko Date: Mon, 6 Mar 2023 09:15:17 +0100 Subject: [PATCH] mm, vmalloc: fix high order __GFP_NOFAIL allocations Gao Xiang has reported that the page allocator complains about high order __GFP_NOFAIL request coming from the vmalloc core: __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] it seems that I have completely missed high order allocation backing vmalloc areas case when implementing __GFP_NOFAIL support. This means that [k]vmalloc at al. can allocate higher order allocations with __GFP_NOFAIL which can trigger OOM killer for non-costly orders easily or cause a lot of reclaim/compaction activity if those requests cannot be satisfied. Fix the issue by falling back to zero order allocations for __GFP_NOFAIL requests if the high order request fails. Fixes: 9376130c390a ("mm/vmalloc: add support for __GFP_NOFAIL") Reported-by: Gao Xiang Signed-off-by: Michal Hocko --- mm/vmalloc.c | 28 +++++++++++++++++++++++----- 1 file changed, 23 insertions(+), 5 deletions(-) diff --git a/mm/vmalloc.c b/mm/vmalloc.c index ef910bf349e1..bef6cf2b4d46 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; @@ -2893,6 +2895,7 @@ vm_area_alloc_pages(gfp_t gfp, int nid, * more permissive. */ if (!order) { + /* bulk allocator doesn't support nofail req. officially */ gfp_t bulk_gfp = gfp & ~__GFP_NOFAIL; while (nr_allocated < nr_pages) { @@ -2931,20 +2934,35 @@ vm_area_alloc_pages(gfp_t gfp, int nid, if (nr != nr_pages_request) break; } + } else if (gfp & __GFP_NOFAIL) { + /* + * Higher order nofail allocations are really expensive and + * potentially dangerous (pre-mature OOM, disruptive reclaim + * and compaction etc. + */ + 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