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 A4F7FC3ABDD for ; Tue, 20 May 2025 14:01:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1BEA56B008A; Tue, 20 May 2025 10:01:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 196156B008C; Tue, 20 May 2025 10:01:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D3C26B0092; Tue, 20 May 2025 10:01:44 -0400 (EDT) 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 E25706B008A for ; Tue, 20 May 2025 10:01:43 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 936A01A03AF for ; Tue, 20 May 2025 14:01:43 +0000 (UTC) X-FDA: 83463449286.17.4C41183 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) by imf24.hostedemail.com (Postfix) with ESMTP id A4FB818000F for ; Tue, 20 May 2025 14:01:41 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Sy5x6vTB; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf24.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747749702; a=rsa-sha256; cv=none; b=rx2oUYPWQaOgUgBzStPYo4nlmtfBMexFpuPSb4ktXUEbnTynE7sFZUBfx6N6lDqqfhMoCf zxE3EsoqNd+js/Kp9s+S0SwUNMu2ThNJl2mN1rQUYMhWJ8jvCsPmspE6mMQU+psk8PJYxn CbhA9dKhco1rpMfdqyfkSUQsAVkx4Gw= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=Sy5x6vTB; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf24.hostedemail.com: domain of kent.overstreet@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747749702; 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=h97csemHNLxAOxFVa08yH6eTv2RpV7guY036p3vP+t8=; b=YBiFKwQUrA2Pne7nDc0fiPgzOILtFi2AUZFAE7HpTJo7Fql+B2IjNT2HhUWlgVQE5ZIjX7 gadeZjhgv9KYsVG7uXMxC05YCTdH1YjMJ6DhhJG7QscDSI5udgYsUkvFHu5ktuXGIZB8xA FNzzbTxVROp9zLumy/jXa0fZU813Iog= Date: Tue, 20 May 2025 10:01:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1747749699; 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=h97csemHNLxAOxFVa08yH6eTv2RpV7guY036p3vP+t8=; b=Sy5x6vTBsLnVOlRksZPFzfJn4ELw3wX02Wx1B0ylbHomDJ0+QRQN1CxQamW5x2V7M7iDD2 hsna1dpXmnZmwko2TKHFFAkCFP145/CAghIFzTQJtM9jx3DxMypSgKi1OqZFT0o+DE1So2 nd0GUNWK9wWHRe+CHxEt44l99/HVsOE= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Usama Arif Cc: Andrew Morton , surenb@google.com, hannes@cmpxchg.org, shakeel.butt@linux.dev, vlad.wing@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH 1/2] mm: slub: allocate slab object extensions non-contiguously Message-ID: <22oihuvcrh5sg3urocw6wbop2v5yni7zinuhywbz7glsee4yoa@gzi5v5fcggdl> References: <20250520122547.1317050-1-usamaarif642@gmail.com> <3divtzm4iapcxwbzxlmfmg3gus75n3rqh43vkjnog456jm2k34@f3rpzvcfk3p6> <6d015d91-e74c-48b3-8bc3-480980a74f9b@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6d015d91-e74c-48b3-8bc3-480980a74f9b@gmail.com> X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: A4FB818000F X-Rspam-User: X-Stat-Signature: q3fmnfsf1oi3fn36zrzz11cnz1ntbpf1 X-HE-Tag: 1747749701-591571 X-HE-Meta: U2FsdGVkX1+UNgmDZeybJgH9SJaL9jP999oou37K2KuQjxuUAT+D56gA4/NCZ/MewrRSXCVv4w0Ie6JUAo4OILIqks6vIcTm4+tJreYo48H1QPmSTB//LbaEhLonGIT2d8ZUTwZV6pOiQ5FPAcAJe8SjVqilxBMG8C9t4LB0cugIDlU+g/rvx0VsZV4nS/SS9qbzF08oSQAP+CVCkxy2ex++lLC2S72Zs6r4f13p/tOY4DuhuIZ7NE+Md1fCmB9lRmuBqEiC9uneX0O5Sa+RABW3JrTpPBLUKX8iKLL/6fOmtdkqFFnwFyQCznX0+zOeABaPQ81cj+I51ODg48ltyANkAUXgb1CKe/IW4PbrnWiflWbc/GhyitgMcf8pYmxi37oqqX8H4yJk45lOegmUbyvLFVqkAfyCWyp2nnG8oJuqHrjH7igjRaMU3rlg52HZ3q3x/Sk13XVhWRt0Q/Y5vD7HK0hhtGdVd1+mUi0EQZ7F9bL3zLG8qX4k6P8JdW3uL6o5PdRNY2EE+vbrG4uTU3FbKtB3nJkR3hhD9eoxbKIZsCChP0aYe5qgJemfwkgxP8/SIwLMKg0yrZA1C1i+EO6Z1q9+AjsnFb1mb3UkSkTAf0hk/NFrxkYaBuaqpXLsgwvKCpl56lfc6RCVVpiNaB3BeLwRPinwLiAD0+E4oUkMb5yMdETk9TaXdAzoVQz8oESrgAfM38cP8FmikpdO4LjTy2/dhlxrPRZeY7Ts8Y6a19a+4Badz44m6Wx3gGMg6+AW4AfZOThyetYGSBlpyq9ZuzXq35rhxV3Bfap+rS5tJ2DqhXmwRiMzU/KdhOWawFzdxZA+UN3iso3QgAHi9+yV+EPsgQ2fSfjbyNxVtrSH9jJ8iudyXhdm3PgcNgOsg88qzWIqmRU5JjWK+lsyNKK3HB8KCc6REFlj1XFGfCfzSIbeBkZtg/l5ViLGGPMbnVOOuojzaqA4V7wrIks UUuokuLi Ii+L9nzPhsgRrectm10/tvW+ma64TDvOylZOsMXZngLo3Izocn9TA/A+hckt12EhNw3/9H4W948k75o5lx7EK0UIoyXQVXqE+UVyHlxXNel42cGD/TVa8h53jsApZujgLaqBJfn2q4Y5iml6qTCn2pCXXjWFKTgH/oHk3LSkb1wq8ub3roKlJXUUzuLqr2acFzBemelqYL0lpjjdQ5UGc8+zfdIHPa3vFVx6vXjheDCKMfVdMdGxvX0gpL3Ay2mmGi+wegcwyDAZ5iQRXSJVoY1+B7durlkihxKubVg8NeI2sI26GHht0aQVwr+tbg7kJL1PdFSfMHrtjGbM= 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 Tue, May 20, 2025 at 02:46:14PM +0100, Usama Arif wrote: > > > On 20/05/2025 14:44, Kent Overstreet wrote: > > On Tue, May 20, 2025 at 01:25:46PM +0100, Usama Arif wrote: > >> When memory allocation profiling is running on memory bound services, > >> allocations greater than order 0 for slab object extensions can fail, > >> for e.g. zs_handle zswap slab which will be 512 objsperslab x 16 bytes > >> per slabobj_ext (order 1 allocation). Use kvcalloc to improve chances > >> of the allocation being successful. > >> > >> Signed-off-by: Usama Arif > >> Reported-by: Vlad Poenaru > >> Closes: https://lore.kernel.org/all/17fab2d6-5a74-4573-bcc3-b75951508f0a@gmail.com/ > >> --- > >> mm/slub.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/mm/slub.c b/mm/slub.c > >> index dc9e729e1d26..bf43c403ead2 100644 > >> --- a/mm/slub.c > >> +++ b/mm/slub.c > >> @@ -1989,7 +1989,7 @@ int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s, > >> gfp &= ~OBJCGS_CLEAR_MASK; > >> /* Prevent recursive extension vector allocation */ > >> gfp |= __GFP_NO_OBJ_EXT; > >> - vec = kcalloc_node(objects, sizeof(struct slabobj_ext), gfp, > >> + vec = kvcalloc_node(objects, sizeof(struct slabobj_ext), gfp, > >> slab_nid(slab)); > > > > And what's the latency going to be on a vmalloc() allocation when we're > > low on memory? > > Would it not be better to get the allocation slighly slower than to not get > it at all? Our behaviour when thrashing sucks, we don't want to do anything to make that worse. There's also the fact that vmalloc doesn't correctly respect gfp flags, so until that gets fixed this doesn't work at all.