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 62B80C36010 for ; Fri, 4 Apr 2025 15:33:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A608280005; Fri, 4 Apr 2025 11:33:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 32E45280001; Fri, 4 Apr 2025 11:33:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1A8A0280005; Fri, 4 Apr 2025 11:33:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E6FD3280001 for ; Fri, 4 Apr 2025 11:33:32 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2ED34C03ED for ; Fri, 4 Apr 2025 15:33:34 +0000 (UTC) X-FDA: 83296755948.18.C421E4F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id 6DAD24000F for ; Fri, 4 Apr 2025 15:33:32 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="ikM/RMtH"; spf=pass (imf12.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743780812; 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=Qz/wk1mY4pn776NbvyTnKyiN27h7CQQkTwQEeTlPUUU=; b=QYCWwyRTXadeSr17NKd5xPfzAfWATBGWqBl/x30t1xndO/fmQLj12KqHnl1v9SBHd4QOU3 dmBlqJQLSp/i1Uo/tUd1A5pjCOlySqpoRPzP+FnQQafTOKw5RYvhjRIw45LxjYwLsViGo4 2lj1L4TP1f4MnygBUGwN9jH5vbkUqLg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743780812; a=rsa-sha256; cv=none; b=cSs1TNDAHaQaRIwIdhvOfjxN9xSNZ8Daj6K8RuwuDA+qKlb164ismHPQLwyDGeNzo8QTbo p9cffU48DABBjfpX1arTZskB8BVcZ2qsEuk1FL7I3foLLFQv9QKwbslTt6Y6oKudW10GYf ESJeBbJGFD6ttQ6ri3LOg82yMme22NA= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="ikM/RMtH"; spf=pass (imf12.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 2D0095C6B7F; Fri, 4 Apr 2025 15:31:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA4E6C4CEDD; Fri, 4 Apr 2025 15:33:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1743780810; bh=y9pu3nJd84VU5yRDTC1QHrt7BnKZdtXq6ZDux9oU/Cs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ikM/RMtHdWuOEtchB5iE+P29zEtdeAdUO3DaoyIxsB1IDAH3gcgNiMDO7OS/vffna PpDDLQ25yQ0WViAKl51WzL6B6CErofHYN5EKd46Ba43YlyII68jncjYYZJ3kVX+nsc GsHgKhpM8a3pqQ4PKG8xhLDFUtSAjs2N35r/nZTrtii7jmTuTNsH+3yiLek7NlQZAb qVJrL/XiNtI7tSZcBvFBwxKnn1degrgfu+UUgUgsps0fatAMM3FG9f2fc9AOLY150W GL8j42skDUprhqfMCmNX9b6QU05g7q/yZ2OOjUp9cMAt8kEzgTNNnMkTyCep1qyyqG 2JC+iT5qrY2rA== Date: Fri, 4 Apr 2025 08:33:30 -0700 From: "Darrick J. Wong" To: Kees Cook Cc: Michal Hocko , Shakeel Butt , Dave Chinner , Yafang Shao , Harry Yoo , joel.granados@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Josef Bacik , linux-mm@kvack.org, Vlastimil Babka Subject: Re: [PATCH] mm: kvmalloc: make kmalloc fast path real fast path Message-ID: <20250404153330.GA6266@frogsfrogsfrogs> References: <20250401073046.51121-1-laoar.shao@gmail.com> <3315D21B-0772-4312-BCFB-402F408B0EF6@kernel.org> <202504030920.EB65CCA2@keescook> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202504030920.EB65CCA2@keescook> X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 6DAD24000F X-Stat-Signature: 7kfm639z157e8nrowr1w7s8ffu3cisoq X-HE-Tag: 1743780812-179681 X-HE-Meta: U2FsdGVkX1+ueBG0JgFjDAnrK4KtdH4IPiWNDncfjoDP/37VJnXWL+5fg9jdOvRg6XDeEdH8w0DHSucbgJryZzE8bFkxDrRleXZbtkosX0dctszQRmfvhcynznsHj5lVhXzTYAZ3Ejiqkc4zDHpSZDeTHSmTOy6cIRPyrbWi67KYJEj1WOBsMFGO007gQJ1+SvwIhaoztPVDR28AJIdK2iPyH5Cjs1qcw3zosGzOcQ7nCu2uTP8wtQPdT7UFeTap7wNla6Cfym3WDsQN9Z/kK4WzuL1Kg+hgyisyDvXIdfARh+KTaSAyC9bo8Ys/pyVRYOa9as3NxXMXbv543Rj8FyrrcGFvv7QlL38eEUnvi5ZD1GRSn493uN8H1cWYmS52AORkvuW0PLHeWUh0fU4B7h+z1k4L7JTfoRRAtdaf00V7ixRVs7kEEXeaauKtPeb3sCiw2oKMsAvdkvLsg6oV/3hNDR6Mz0VbBhjB1lk/LBcP4Bbhz5fQcA4mBm7dYXAWx/2RPa7itL2F9ouV6Vj5ZYhgbNYTF99NCNtniT84kMQKIZbJqCWRwCsU0hfP92QAlV7YA3DUTOrnhekPWgbyvtu9C9Ei2NGj3zRk3Kz9H8oqbuvodFUGJSg1H1eezSN0zdQijcFEn9Ota5f6Dtz1+6RxLoZ6SrfH6HJ1lelM/QGyU6aRnqVhk7jW5u2Muh6+CrsggVaJR5NXaY0XwVy+2SwqumVrPnVOZWQdFR3J54gJRtzFRKxeSXxDuGnxR3crqMxMg6UkIUwYM8NwA0Os+T9WTAi75buN3yDz96kfAi1xsJexu1/UirMKH9xQH807EWX8oO0NP1NvmUqI9k5jD3G3kdQXbwH1lU7OpRFbpncDqb080QJyyPqiw3BVbeUaT9Qb1EtwtBDY5o7XxNGFKvmhWPD2PDQOWxn06UqUGeKz0Kk67V3a3TZdMXRsb+KC4DeRMppj9Rr4/WxJmZ+ AbFdL1vR vZsX9XuuP6W8HUHQJ57Z6qOZpT+ts2H4mNXtayIH1MpYVwcTvQe1TeC7VevnKsi5hP0CRYYJJVT0tTLLsaliw6vLTQm2JFr6eMwLdu6UoKH/d1y6i5UG11/FAnJw0HbZuHAdYks3gCXeXkp56WDziPhtO3yFYQuFvbadn0iRCv9uXSM/NAtANMYdaZEhct9BaX7pr8vpVuB4H5f6z1vHd6duskZlGvhFyfqKaXDNVzkb4m99nLCFWp69C8W3mFXRWYIcXv6WIVolTcnv6Nxdz+vjf2NPJEavCeUI7+Y2TCR9qLWmcLr2V6w5EJiaJhxwvj3SavUlb7iPDsDpq7kmqgCqZTSn/fFZbW/VwY4MFRCXiC2HSn6U6m1GqpRKZobLxZe06HRxK8aGWaUrE2S/LuAxzYw== 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: List-Subscribe: List-Unsubscribe: On Thu, Apr 03, 2025 at 09:21:50AM -0700, Kees Cook wrote: > On Thu, Apr 03, 2025 at 09:43:39AM +0200, Michal Hocko wrote: > > There are users like xfs which need larger allocations with NOFAIL > > sementic. They are not using kvmalloc currently because the current > > implementation tries too hard to allocate through the kmalloc path > > which causes a lot of direct reclaim and compaction and that hurts > > performance a lot (see 8dc9384b7d75 ("xfs: reduce kvmalloc overhead for > > CIL shadow buffers") for more details). > > > > kvmalloc does support __GFP_RETRY_MAYFAIL semantic to express that > > kmalloc (physically contiguous) allocation is preferred and we should go > > more aggressive to make it happen. There is currently no way to express > > that kmalloc should be very lightweight and as it has been argued [1] > > this mode should be default to support kvmalloc(NOFAIL) with a > > lightweight kmalloc path which is currently impossible to express as > > __GFP_NOFAIL cannot be combined by any other reclaim modifiers. > > > > This patch makes all kmalloc allocations GFP_NOWAIT unless > > __GFP_RETRY_MAYFAIL is provided to kvmalloc. This allows to support both > > fail fast and retry hard on physically contiguous memory with vmalloc > > fallback. > > > > There is a potential downside that relatively small allocations (smaller > > than PAGE_ALLOC_COSTLY_ORDER) could fallback to vmalloc too easily and > > cause page block fragmentation. We cannot really rule that out but it > > seems that xlog_cil_kvmalloc use doesn't indicate this to be happening. > > > > [1] https://lore.kernel.org/all/Z-3i1wATGh6vI8x8@dread.disaster.area/T/#u > > Signed-off-by: Michal Hocko > > Thanks for finding a solution for this! It makes way more sense to me to > kick over to vmap by default for kvmalloc users. Are 32-bit kernels still constrained by a small(ish) vmalloc space? It's all fine for xlog_kvmalloc which will continue looping until something makes progress, but tuning for those platforms aren't a priority for most xfs developers AFAIK. --D > > --- > > mm/slub.c | 8 +++++--- > > 1 file changed, 5 insertions(+), 3 deletions(-) > > > > diff --git a/mm/slub.c b/mm/slub.c > > index b46f87662e71..2da40c2f6478 100644 > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -4972,14 +4972,16 @@ static gfp_t kmalloc_gfp_adjust(gfp_t flags, size_t size) > > * We want to attempt a large physically contiguous block first because > > * it is less likely to fragment multiple larger blocks and therefore > > * contribute to a long term fragmentation less than vmalloc fallback. > > - * However make sure that larger requests are not too disruptive - no > > - * OOM killer and no allocation failure warnings as we have a fallback. > > + * However make sure that larger requests are not too disruptive - i.e. > > + * do not direct reclaim unless physically continuous memory is preferred > > + * (__GFP_RETRY_MAYFAIL mode). We still kick in kswapd/kcompactd to start > > + * working in the background but the allocation itself. > > I think a word is missing here? "...but do the allocation..." or > "...allocation itself happens" ? > > -- > Kees Cook >