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 44E07C3DA6D for ; Tue, 20 May 2025 13:44:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D863E6B0082; Tue, 20 May 2025 09:44:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D5E9D6B0088; Tue, 20 May 2025 09:44:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C9B8C6B0089; Tue, 20 May 2025 09:44:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id A87E36B0082 for ; Tue, 20 May 2025 09:44:12 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 16ABB8034A for ; Tue, 20 May 2025 13:44:12 +0000 (UTC) X-FDA: 83463405144.02.85C4E21 Received: from out-180.mta1.migadu.com (out-180.mta1.migadu.com [95.215.58.180]) by imf25.hostedemail.com (Postfix) with ESMTP id 19DAFA0009 for ; Tue, 20 May 2025 13:44:09 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=i3jOTG7h; spf=pass (imf25.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.180 as permitted sender) smtp.mailfrom=kent.overstreet@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=1747748650; 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=TGr+kSgbuRg7CaxuG8M/R7pLnPrjwbA83Xss8apQ3wY=; b=NEwVQxHru2i5SDZ3aR6bCG5XDQ18g6BhsQZU/amMocNZWNT8D4A3ndY/yu78Ev2tE7LQ2t G6DPI6+HWtwsn7tU/fVz4OiA0OoEVxr/5nQM0sTNYfPoqVDQDOnrRMEXgZX7YogWSjC5sh IaddDGs/kszAd9cNpTMF4vYwqg/O+ik= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=i3jOTG7h; spf=pass (imf25.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.180 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747748650; a=rsa-sha256; cv=none; b=A6va7io0jXhPH4vmVY54pZ74YXIH88XWv8k2XucuvKQjWsuVe0iOz/+e0Y9rAuFxwIhpQJ 12wDxmddQIHKy8/lOCXvCVYicrDhJh8VgQjuK5ORwsqPOmUIUxJa+r7EH8xylrpy68bdyZ rw+JgwxusIuiAB72gCO2kvrYJVtjpVQ= Date: Tue, 20 May 2025 09:44:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1747748647; 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=TGr+kSgbuRg7CaxuG8M/R7pLnPrjwbA83Xss8apQ3wY=; b=i3jOTG7hT8HlPiGsOD1Luahi1hnmA+d00NewRPtzTd36ZvmUS4zHHmPD5GdMbPI7EPBrVK SL0DSu2BB/MCt/iPV4jmMCrrrTOlthAy9o0r/oPTg7RgbgqLGwIW+/nOf2wsNC0w+9eYUj PjfgHUFqWHYwKpi7xJDq6EzmOCpo3RE= 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: <3divtzm4iapcxwbzxlmfmg3gus75n3rqh43vkjnog456jm2k34@f3rpzvcfk3p6> References: <20250520122547.1317050-1-usamaarif642@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250520122547.1317050-1-usamaarif642@gmail.com> X-Migadu-Flow: FLOW_OUT X-Stat-Signature: ndo6kdsx3599rrezth3r5xikgubmw6ij X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 19DAFA0009 X-HE-Tag: 1747748649-358406 X-HE-Meta: U2FsdGVkX1+JFanhuAZpB2W/clldWkkXTvJ4p11HwBGGZebn/5MiqQHR+1EmjMDp5O18Li0n89gAF3FiShWi7xGfA0dnmIMAb0eJwHQ+/UG7WeOZ1KcaZMUqRFhMVrPLA0EZkdKrKisaiFkGv3Ua+nTt9R/eD62s/RMvzSelyanChPCYelurae7jKNVbp+vk2AvMN+v2jU29waGJMwSrFMQ+a+kV1bmhmSxZRbYP/sW7QEfeANkYanpG2X0TAcfxJWTPISh5dMQnJhYKP/9co1IyF5g9kE3SSgp185QrQ/OAN2JerxRUQHYDqIIco2R7er7KlDf+qd0AO1+M6WDVDUCObOe/zUEMqThM90GTpyqL8TRBiVFIW7mkAqEz0BxNuQBC5JYv18oEfkvMVuCQcxl+uzXIwZ6++jyoB8hIbCtkDJ+ih8VFoSrh424xNpVb/slHsAfLGguk67To+UoPiRFIvTb+1m+C9GLDxZH/D5Tf9e3/hEJJoVtO/LkRvHUJTy3pLpZHwLwPqn56iJXQF3GDbUSG6S8Y+FpQ1DSPH7chPQlywNXYKtx/ReKs9WuaMZclM7ykFDd5Dy/fGWX44/SPohG4qB+ZezMgUKBfGc72fySQqMN/7QNbWHvhFevEQycp71sAg2fZHY1BWEl5dZPjsFazOrNVyDlEYmafBuKX7jTiE8gvu/MLKh594gci2gu0ozam/Jk5yoNtk5QLZtp+zh1SSWtd6Y9OtMFjDq0950gDSUXVUhkqvoEiInqq6SPhmbpzo8UTbWCc2+RrN7L8SZIEPxhCs3YZRQPXpexNl+oNlMJ1O58Y7rr86yZ1poStIC0RPM9V7UgYBReOKRLkX8khFoMCkhWQ5lHE+bEa4d2uA6DkqUfzKt6ef+RQKnhLwZbyUwIb5KAFdSbZ4AuzpoOphB8QtEPqT75ZthqHmUaMlc6+FhVUlgJHIrVMBlX9yORzMaWagmuIhSF 52CmbYfx MpbSvUTQkNdPqvSLZ45W5WrbwydvU4uqtp+QlVNUlTgi3WFOZI6/WficsfMruA3WU4d1YTxexi2ABsKyEN0MS7ShfmIGKeeRSE/vAIVNhVF+GIL8xYxC0syuuxGwHK7AAu3HkyVBEFcaRO3ndQOfBV5sc6oTAXkP+rprPw3l0Ew6L+5haIgWr5ChHnAHXT32mO454ajqBT+OuNpR29YHvXbuGwhZF8Y9hDzgWvyn/lKTIRFvV2VsiMi0lqup/g3U11ZmV9/82ynCm0Ja8rhBV2j8TVHnuDth8vflO5TAIn3XHCG3zUvi10ByXYxjDwQZ3vjTzzaLb9rc2P7s= 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 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?