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 46CF9C3DA6D for ; Tue, 20 May 2025 16:41:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B084C6B008A; Tue, 20 May 2025 12:41:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AB8FD6B0093; Tue, 20 May 2025 12:41:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9CF736B0098; Tue, 20 May 2025 12:41:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 818536B008A for ; Tue, 20 May 2025 12:41:33 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 2B6191606AD for ; Tue, 20 May 2025 16:41:33 +0000 (UTC) X-FDA: 83463852066.05.54CFC4D Received: from out-182.mta1.migadu.com (out-182.mta1.migadu.com [95.215.58.182]) by imf19.hostedemail.com (Postfix) with ESMTP id ECFD11A0004 for ; Tue, 20 May 2025 16:41:30 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=O4O+QXIT; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf19.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.182 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=1747759291; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yesL9v5oI+2cUm8MiDnev15NKhDO2Hb+odQB+4YCNWM=; b=FLLxGqxk3XGQsBq6Fqt1wijmdkXMDGHy0as22SFr11q8g4Avw0KicvtOEKOXJzEzPr2emV 39P11SZ0ahwiDRd24TocVh9NcWwMcO+RR30XIvvANNuycJNJkIiNJ3z1s49vUU/vty1iuS 3TZIL2pztIgJxHGa72NUZXQzET2rXJs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747759291; a=rsa-sha256; cv=none; b=tSN+ntQJp+7n1mTCFe6KAW4mzyqMxv+uMUFSIUL4g/RroPhM1Mq8RkTp4ie37ZmdvanF54 Xo5r07OHl+F1sgsTDiQH3gN2FO13u3vtcn2XcGOkg+fMguDCPU7+qhhQHnTIXRFgwvE1dy UVbZc2BSWA0vyvHdT+bGfT3AExXV1Lo= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=O4O+QXIT; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf19.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.182 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev Date: Tue, 20 May 2025 12:41:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1747759288; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=yesL9v5oI+2cUm8MiDnev15NKhDO2Hb+odQB+4YCNWM=; b=O4O+QXITIhBx+t//BHiXt6DJlx9SEukou54zmJlhbo6vcJIRGOe1ybUjFRTse5adKBXqIn jOoXYXwHmgeHt3BG99WVkpXi5c4c/o+bbowVaRkHcf2UIvsAqw6pddn7EvyIvVtKFDgJlk XTVB+HRg/zke9xNpjRSoyLUL0idIl1U= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: Suren Baghdasaryan Cc: Usama Arif , Andrew Morton , 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: 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: gztxacusb7iufk1p7y3fjmpohahkzpg3 X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: ECFD11A0004 X-HE-Tag: 1747759290-856399 X-HE-Meta: U2FsdGVkX18LdwC6ri4UKek0lVvkberwmtlFk/UJmelTPQ7vFQ0W3Zgir2KMgzudgCZw9TvIsF8xgVK/yhjRx7GLDHhSfDRp01XtXhlFRWYldsYhuoUSmUsBx/4RBPd4cOl/1P0thC1uObbRCpA+a4cQ2e7MUUyKeYVtFC2pRvFN8eHQV1dN118/MvLHaCI5xGcJ5eFT2goFoV4RBuuLLmLbSKaQmhhLgQQjndShwbtlipBBjOAQtQqjt/9Ltllhx6c88io5mv+lkdn0UUxN6vCUKQ4wfPPRG7rPvE/pehMnjGYu/Olhp6HNW2LM53HvoOBXn/nV4DHO4KGA8V6DFJwFdS+6y455FKlA9pLNhIj8498kySXy+Xqed4uLb9kL9n+64gGTZOa2d3f8+LzgeM6qmBWqTJz0iLFcZqFtmCkynf4Q2rIQQEot3AONlnbhGrtlASZVVwKXdtmu0BxVhlIPd5F7IkqE4cNzeaAqPMCCNDueMrP2CtPAGRtNb/ceEaw4zoR4eTsgWt9LYIzrqNrJ5TnHmN3Ikra45J06VZ//AeML6fSjx4yVBapiecmrNtOzrug2fpXCXzYYBKxewVG3SUqdagGF2a9axNaUmCi8ivzSR2qzUPdUWkNhI1hGk81tSeKfw7v6xGJEk2Rj4PeVjmHNrR4feWRb2CIPYNo511MTe+J3snHpYxHF1HN418r4q9RE+hlPDbhkBlaK9CHn2nHPeW5/kwL/C6IzfH5xdeVz+j5f2YwKives92Zez9ElpezALQmbi3HJ2A7+EynCr6oDjKuSVDftQw0LbVnByshoWFiNIU+qbiS7ArOVkJu/Z1wg6POgXfj1ImQTZfxUpWvg4mOPw7EXP5enhznuSKZnxDUqqV1UtXTq296tOPMsPWrSxgDEn5WiCrjbuNYbNstuFiqCv+E36rYTqsJohPglAPyw3CUOW3ibNcg1k4ErAhhOkpcWLXAB8bv ATIr+GnR vmIlvFBL3nMonwXrsMi5/6SeFY25Mi8gt6+5GIZd+vS+0u0EMWozfjQlZe1ZhG/O0JVSze9JGWZd6SzYqkXHPBD7qsNyx3wORqHK4G+FdUKfGdZljaNct24agBg8PbNBI5UXMaBFkRWymNRWYVfgBDzsgoKtc7PgbJITWwtcXb+pcwoE4rF9Ms34OnQt8H5yMMraj2a3HAMrL1Op5gWcTZBy1tTtnDdrI4zKiUtYNqcDYxvUd0E9E/vsBOBiztERAt1ceyQra4gVaEYUWVbD0++zccLBHP70RNekzhd4XBulolKoFl6hXNJxOlUPyAHeVAPQyw9ejPMXArpIE95hwIcFh2xTtkvWBcf5VyhW3DKV7vnlGsidRdAv2c6A1m4BWaeHuJE/4pRDBhQOoNscABm6m6/mQIU1fYvHc 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 08:20:38AM -0700, Suren Baghdasaryan wrote: > On Tue, May 20, 2025 at 7:13 AM Usama Arif wrote: > > > > > > > > On 20/05/2025 14:46, 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? > > > > Also a majority of them are less than 1 page. kvmalloc of less than 1 page > > falls back to kmalloc. So vmalloc will only be on those greater than 1 page > > size, which are in the minority (for e.g. zs_handle, request_sock_subflow_v6, > > request_sock_subflow_v4...). > > Not just the majority. For all of these kvmalloc allocations kmalloc > will be tried first and vmalloc will be used only if the former > failed: https://elixir.bootlin.com/linux/v6.14.7/source/mm/util.c#L665 > That's why I think this should not regress normal case when slab has > enough space to satisfy the allocation. And you really should consider just letting the extension vector allocation fail if we're under that much memory pressure. Failing allocations is an important mechanism for load shedding, otherwise stuff just piles up - it's a big cause of our terrible behaviour when we're thrashing. It's equivalent to bufferbloat in the networking world.