[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <107f67de-da5a-766b-1cb9-b107f407831b@redhat.com>
Date: Fri, 18 Aug 2023 21:59:38 +0200
From: Jesper Dangaard Brouer <jbrouer@...hat.com>
To: Jakub Kicinski <kuba@...nel.org>, Jesper Dangaard Brouer <hawk@...nel.org>
Cc: brouer@...hat.com, netdev@...r.kernel.org, vbabka@...e.cz,
Eric Dumazet <eric.dumazet@...il.com>, "David S. Miller"
<davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mgorman@...hsingularity.net>, Christoph Lameter <cl@...ux.com>,
roman.gushchin@...ux.dev, dsterba@...e.com
Subject: Re: [PATCH net] net: use SLAB_NO_MERGE for kmem_cache
skbuff_head_cache
On 18/08/2023 18.26, Jakub Kicinski wrote:
> On Tue, 15 Aug 2023 17:17:36 +0200 Jesper Dangaard Brouer wrote:
>> Subject: [PATCH net] net: use SLAB_NO_MERGE for kmem_cache skbuff_head_cache
>
> Has this been a problem "forever"?
> We're getting late in the release cycle for non-regression & non-crash
> changes, even if small regression potential..
>
This patch is not dangerous ;-)
SKB slab/kmem_cache is already almost always "no_merge" (due to the
flags it uses), but certain kernel .config combinations can cause it to
be merged (with other 256 bytes slabs). I happen to hit this config
combination in my testlab, and noticed the problem slight performance
impact. If anything this patch makes it more consistent.
--Jesper
Powered by blists - more mailing lists