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 DE11CC36014 for ; Thu, 3 Apr 2025 18:30:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 26B70280008; Thu, 3 Apr 2025 14:30:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 215DC280005; Thu, 3 Apr 2025 14:30:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1056C280008; Thu, 3 Apr 2025 14:30:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id E6791280005 for ; Thu, 3 Apr 2025 14:30:33 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C7D8058FB4 for ; Thu, 3 Apr 2025 18:30:33 +0000 (UTC) X-FDA: 83293573146.03.EF77814 Received: from out-179.mta1.migadu.com (out-179.mta1.migadu.com [95.215.58.179]) by imf26.hostedemail.com (Postfix) with ESMTP id BF92A140007 for ; Thu, 3 Apr 2025 18:30:31 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="pr/Hcdy5"; spf=pass (imf26.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.179 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743705032; 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=ArYKiUFMnEOVml+ahZzr+rsVltz9Am8Fwrx6AQaomzI=; b=Aol1S2L0Bdn+ZjV+moJnsgSd5wZDc033CVIr+N/z4xx/2HRr2WOxNbueILebzyKsCosqgl JKXKCKacw/r6vyq1t8jbGmzfgbxVDoOuflAOkLpqI0pPMnZm6/SiIxvVOq41Ce55iF8oKv wATEcnbgeWqzBmP62o+BrCJhfgsUB1U= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743705032; a=rsa-sha256; cv=none; b=msDjh0RDbNpuLLCORUigGJ7QaurMVoP3z1sdacH+S8ftVK7ssChSRiYHO3osepz6BSv1ek MIU4HJiSi8PGuqb+tItC4WQLyEuw6jzWctMnH1BZ904JRv+WZMJtf0Sepy9gz6qDz05ZLn GFK55VVo1CuXuoASNYY3Jq4AILMBTF8= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="pr/Hcdy5"; spf=pass (imf26.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.179 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Thu, 3 Apr 2025 11:30:23 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1743705029; h=from:from:reply-to:subject:subject: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=ArYKiUFMnEOVml+ahZzr+rsVltz9Am8Fwrx6AQaomzI=; b=pr/Hcdy5U+g8jz5usJ4LCnof/q9gv8w3IYRENXLye3PGpA1C+lLUknPgex7+yH2vJyb2Ar kcUAn6OVbfkdg3+MQDBiq6/rE7BInTiX6vqujAODHnVOQucHSMbbszBa1fYHe5oERwY0mP Ywxc1xrb4yQ+R3J0PxdhY1SFyMGISwM= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Michal Hocko Cc: Dave Chinner , Yafang Shao , Harry Yoo , Kees Cook , 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: References: <20250401073046.51121-1-laoar.shao@gmail.com> <3315D21B-0772-4312-BCFB-402F408B0EF6@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: hquksozfsp18tmoaw3u3cbeg1rp81363 X-Rspam-User: X-Rspamd-Queue-Id: BF92A140007 X-Rspamd-Server: rspam08 X-HE-Tag: 1743705031-465713 X-HE-Meta: U2FsdGVkX18cR0FHihyf8N+RwPS+/WnIL0+2h3b7uZUxYayb1zLscCXm0ILz3Jl8DeJtR7et6WjctNdr+5LZyg6KD3+ymVKPfam0o5geXsPX+r0h4Ium7DTWBrwLWGYV4VZu18CADXXu6hIzQHjah9FLikzIHz9c1I67NxhZGt+0EEvcyQWtDyw4YHLnf6/X5gIJTUHlhSyCfAueoL3jDrPBuMxH/Eo5uoRAwGEruMI+h2jj8q5lCzqHIrYgnfOwQBr6dLwXb2ODypXlv3oupiFZvKbABWDCh6UUA0aPOZQAN0pJNP3K12Ujl7w7YYfYCQoCjfHOVGMJXnEHkCHMlt6x0gV/pFLmZJbyAKiupppvmJzWu7e0o1M3VkB3BqDJzvD6QXbbZ+gAq7+cOhyYIPellHAbyXQHU8XFo6C9yaEBjWNoVuoGNzNuOygoC4niadnwfcz81dlqMiLzOhoRhZO08dINiUbwaamQKLQmXhejymkOiCsppn9kLC5I3+lPKockxBuNmqtoAy2ah0YJF0nc6hMOk3ZVfoW2zV47exS83I567hAXLt0QndWc+1BoskJ9QtMhU8oUXEn7PR30O71jxQgIMHRK89Xhrt+aUExdWDw6pR8P44DQeYzJXxgssSB18c6LjzF8KLrZwbaDGnwlOO8OFo6PukP+qEPt4rVqcJu4x4yBbSR+wY6za4KnJD4BcHdlvaB1tO0UKeHoVUJyCnWzOUOm0YPDiSw9GudTQmTQdUUnmgYo75a68OUaXfRbZhiXLBfuB8/7sgT+WBwEBmtaxYUGzRjQy8yitKqSja57JU4Zoadg4mPMNjii5EIBE4FzCWnspYU2Uwtmi0Y4EEYaOujX47HywQ7hl88hes+qQYIjBenc10VlDA8A+/CCPqjLf1LVKvPkLqJahk9hVFByjSN5UnaueATCd8msMkotom34jIF4pjNxTjKlvkx9or32kclDYnY3QRw tYgdGmBW 1y5H8ikf2il8MP+iGxWI5ojEYllSpaKivE4bi4CgticUee0LH8auDcK0oF2IXpZgyWRoS7/avRfOPSfNsbLgBep6OqlJALdhnzgc18X/fCylQugKCo2heusaUNpG13lp26Bt3NMJoR/Kx3kyWMn9kIsIX77wwFtA8JIbAbsRBBCI2l2/CJbXMf5KlH2iH+VW5gwOJL+Cqf0HJYGyukz+QlpRZbBVgetdRUL1HYoAOCgILt4nzu0OrhVt3CqciKuyfdWMrk/ccyRx+rs5OcoMhIJxvG//D/KADBHnyR5b/w72O6C7r0s6H/a0hKC/WA18vQR1QC0vn2kXkAlc= 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: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 Acked-by: Shakeel Butt