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 AE161C004D4 for ; Wed, 18 Jan 2023 05:17:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B26D76B0074; Wed, 18 Jan 2023 00:17:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AD7146B0075; Wed, 18 Jan 2023 00:17:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 99E8E6B0078; Wed, 18 Jan 2023 00:17:14 -0500 (EST) 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 7DA286B0074 for ; Wed, 18 Jan 2023 00:17:14 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 3B4D2A04A3 for ; Wed, 18 Jan 2023 05:17:14 +0000 (UTC) X-FDA: 80366761188.13.51973CD Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf25.hostedemail.com (Postfix) with ESMTP id 69D7BA0012 for ; Wed, 18 Jan 2023 05:17:11 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=AopJM9Ow; spf=none (imf25.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674019032; 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=zpeZ7xJdduTbUjubbB3znu1VjyoPIaNapdi9kr0F5ds=; b=htavjfV7kaB8GOemZ8B2Gl0Ynfsft24xKLVdPyE086kbz0kW848RCn0EO4bI0RehuNfTP4 3YgagRGNSrZttHvHdNtyXPsVI+RQp9oY0/zwB4Tgvp1YvNM6tv7kO3uzGEgdClQO1W7Iaz hNz31fpgX77RqllVx8QxLExJjQop0FI= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=AopJM9Ow; spf=none (imf25.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674019032; a=rsa-sha256; cv=none; b=NYnF4eqPeX2chHPwP0mSeOsqDXcTOcF7Iw4F6wqPnkShealfPSIozc9eQ7ISQsSwFIRVuD luHgXQTG8+MYJ8qSolWSrFxDfme5KsFWSlg++nMVEE5q7H3FAkdaWuQD7+cNfYqQn7dFZX hjR8U0xGAEmeF1iprkfU+2vDHzHMLvM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=zpeZ7xJdduTbUjubbB3znu1VjyoPIaNapdi9kr0F5ds=; b=AopJM9OwFcbu6lZB24J/xdjB2R Pp3wgRbLaC47dvEN+l5OHHmVpTNePAAiNyfvS2Mz2P5r9o/jNkS3zcwsz/syab6SwPHq7rlRlVBNo K0RKYM2Iz+VV1mR6mQYV7e0jnkuBkowsSL8WPE4I0uXOuPk3/TZYXA7yXnd/iEYq+gWYXnaikP0fq 4AVOSNVkIwm0VqXcsY+CZ+1Ydqmts2kdDFmWqDjY+odNgwGZZ/kH0sc2TOycAt8llqAHknFHOIDAK F0Ya+KSmgmLBzquW0ii5ak23NIIOdz5rnCa9KWflx5uN/LmhePzmmhdVtk9g5MEJJlBU1YQ4mGkGh MbFMbQmA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pI0p1-00ANE1-7k; Wed, 18 Jan 2023 05:17:15 +0000 Date: Wed, 18 Jan 2023 05:17:15 +0000 From: Matthew Wilcox To: Christoph Lameter Cc: Jesper Dangaard Brouer , netdev@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Mel Gorman , Joonsoo Kim , penberg@kernel.org, vbabka@suse.cz, Jakub Kicinski , "David S. Miller" , edumazet@google.com, pabeni@redhat.com Subject: Re: [PATCH RFC] mm+net: allow to set kmem_cache create flag for SLAB_NEVER_MERGE Message-ID: References: <167396280045.539803.7540459812377220500.stgit@firesoul> <36f5761f-d4d9-4ec9-a64-7a6c6c8b956f@gentwo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <36f5761f-d4d9-4ec9-a64-7a6c6c8b956f@gentwo.de> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 69D7BA0012 X-Stat-Signature: 5q4gjw4tjz646i95e51rb8xdy7pbeypi X-Rspam-User: X-HE-Tag: 1674019031-726732 X-HE-Meta: U2FsdGVkX19gIff3Ks8Dyvq6iKJnuZZqF7N+6l753RY3pZ1O6kWg8jkEPFzTt5mHhD5vUAKV4c2GG3UzqLUx5TFwkNpCPb8DAGdl7QZJ7A3TwVJq4LNpv1gScS0wyz1PeM3rjWI7gqTgs980MLA8gdOyFZm+iSDKpbRtSBMd+RYcp4Yhky+KqnHypDUrhwYVe487QuJX68XLz+famnHVPUs6PuUhnkHrWWSDe0M3ZQKGjkemWEPgsIbbvIBkkYDlrpVCsm+5qyV4jiiQ9hdI/D4qQoO//3sxdxayIiTqyPBhkdPj1islAYO3xiVygMQjT8kh4sOd0sEL0dWXZWcIUurXfBwoBf74R7Oj2mUuPnNmdCWTgIcoTVdF+qgGDw0WSNzVqBf8zDV38ZD/pz/Y04huZzxACzSkBIjsL9naOkF9pBJSWEc98NEtBrIo4CAJ4nxOp+j7FnHSk6iYMQI1JVgA3sm50Ea2dIW4qm2pDgCwjNWHtK5PlTyI11G/258Q78QLEpkoff6BYQdZJ3oiMJ4tvH7z4Fh2MEwProc8/9/QPHLQx1grOTRsUmMYoKigI4yq1K2beQa0e1cTpmx6f3KxEWkZSXaJMx3Fc7qch01u8ElxnPoiPwF5u3ZQHHlG/BHy+I5MlKRa5/8vKelAb0JIaceCXmDBGRRn3PTn3aqvaLSEa4X7x4jWaw29hRqx+M9H247maSbprhEsk80T7jwYMqPpfgiHfmaiRhERr7GkjT46Us0YlNxjfCLK+IKwS++hxl2KIrlcBsXDXj1WVMlO7QGc+wCruAmDJva4oIlz/tP2U2ld+MtMf9jTKPLUg/X2whJJ0AzG+VLtV9yhjmVvtJqtaGws5rasolB0TSi/jjo63K0+ex0AjDtl3ygX/ri7Oi8Wvz7DwfDtv3W2+A== 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: On Tue, Jan 17, 2023 at 03:54:34PM +0100, Christoph Lameter wrote: > On Tue, 17 Jan 2023, Jesper Dangaard Brouer wrote: > > > When running different network performance microbenchmarks, I started > > to notice that performance was reduced (slightly) when machines had > > longer uptimes. I believe the cause was 'skbuff_head_cache' got > > aliased/merged into the general slub for 256 bytes sized objects (with > > my kernel config, without CONFIG_HARDENED_USERCOPY). > > Well that is a common effect that we see in multiple subsystems. This is > due to general memory fragmentation. Depending on the prior load the > performance could actually be better after some runtime if the caches are > populated avoiding the page allocator etc. The page allocator isn't _that_ expensive. I could see updating several slabs being more expensive than allocating a new page. > The merging could actually be beneficial since there may be more partial > slabs to allocate from and thus avoiding expensive calls to the page > allocator. What might be more effective is allocating larger order slabs. I see that kmalloc-256 allocates a pair of pages and manages 32 objects within that pair. It should perform better in Jesper's scenario if it allocated 4 pages and managed 64 objects per slab. Simplest way to test that should be booting a kernel with 'slub_min_order=2'. Does that help matters at all, Jesper? You could also try slub_min_order=3. Going above that starts to get a bit sketchy.