[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211009004058.GA4992@kvm.asia-northeast3-a.c.our-ratio-313919.internal>
Date: Sat, 9 Oct 2021 00:40:58 +0000
From: Hyeonggon Yoo <42.hyeyoo@...il.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Christoph Lameter <cl@...ux.com>,
Pekka Enberg <penberg@...nel.org>,
David Rientjes <rientjes@...gle.com>,
Joonsoo Kim <iamjoonsoo.kim@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [RFC] Some questions and an idea on SLUB/SLAB
On Sat, Oct 09, 2021 at 01:33:43AM +0100, Matthew Wilcox wrote:
> On Sat, Oct 09, 2021 at 12:19:03AM +0000, Hyeonggon Yoo wrote:
> > - Is there a reason that SLUB does not implement cache coloring?
> > it will help utilizing hardware cache. Especially in block layer,
> > they are literally *squeezing* its performance now.
>
> Have you tried turning off cache colouring in SLAB and seeing if
> performance changes? My impression is that it's useful for caches
> with low associativity (direct mapped / 2-way / 4-way), but loses
> its effectiveness for caches with higher associativity. For example,
> my laptop:
>
> L1 Data Cache: 48KB, 12-way associative, 64 byte line size
> L1 Instruction Cache: 32KB, 8-way associative, 64 byte line size
> L2 Unified Cache: 1280KB, 20-way associative, 64 byte line size
> L3 Unified Cache: 12288KB, 12-way associative, 64 byte line size
>
> I very much doubt that cache colouring is still useful for this machine.
Hello Matthew,
What benchmark did you use for test?
-
Hyeonggon
Powered by blists - more mailing lists