On Mon, Nov 09, 2015 at 06:36:09PM +, Catalin Marinas wrote:
> On Mon, Nov 09, 2015 at 04:41:58PM +0900, Joonsoo Kim wrote:
> > 2015-11-05 21:17 GMT+09:00 Catalin Marinas :
> > > On Thu, Nov 05, 2015 at 08:45:08PM +0900, Joonsoo Kim wrote:
> > >> If it isn't possible, is there another way to re
On Mon, Nov 09, 2015 at 04:41:58PM +0900, Joonsoo Kim wrote:
> 2015-11-05 21:17 GMT+09:00 Catalin Marinas :
> > On Thu, Nov 05, 2015 at 08:45:08PM +0900, Joonsoo Kim wrote:
> >> If it isn't possible, is there another way to reduce memory waste due to
> >> increase of dma alignment requirement in ar
2015-11-05 21:17 GMT+09:00 Catalin Marinas :
> On Thu, Nov 05, 2015 at 08:45:08PM +0900, Joonsoo Kim wrote:
>> 2015-11-05 19:32 GMT+09:00 Catalin Marinas :
>> > On ARM we have a notion of cache writeback granule (CWG) which tells us
>> > "the maximum size of memory that can be overwritten as a resu
On Thu, Nov 05, 2015 at 08:45:08PM +0900, Joonsoo Kim wrote:
> 2015-11-05 19:32 GMT+09:00 Catalin Marinas :
> > On ARM we have a notion of cache writeback granule (CWG) which tells us
> > "the maximum size of memory that can be overwritten as a result of the
> > eviction of a cache entry that has h
2015-11-05 19:32 GMT+09:00 Catalin Marinas :
> On Thu, Nov 05, 2015 at 01:40:14PM +0900, Joonsoo Kim wrote:
>> On Tue, Sep 22, 2015 at 07:59:48PM +0200, Robert Richter wrote:
>> > From: Tirumalesh Chalamarla
>> >
>> > Increase the standard cacheline size to avoid having locks in the same
>> > cach
On Thu, Nov 05, 2015 at 01:40:14PM +0900, Joonsoo Kim wrote:
> On Tue, Sep 22, 2015 at 07:59:48PM +0200, Robert Richter wrote:
> > From: Tirumalesh Chalamarla
> >
> > Increase the standard cacheline size to avoid having locks in the same
> > cacheline.
> >
> > Cavium's ThunderX core implements c
On Tue, Sep 22, 2015 at 07:59:48PM +0200, Robert Richter wrote:
> From: Tirumalesh Chalamarla
>
> Increase the standard cacheline size to avoid having locks in the same
> cacheline.
>
> Cavium's ThunderX core implements cache lines of 128 byte size. With
> current granulare size of 64 bytes (L1_
On Wed, Nov 04, 2015 at 03:39:10PM +, Catalin Marinas wrote:
> On Wed, Nov 04, 2015 at 09:28:34AM -0600, Christoph Lameter wrote:
> > On Wed, 4 Nov 2015, Catalin Marinas wrote:
> >
> > > BTW, assuming L1_CACHE_BYTES is 512 (I don't ever see this happening but
> > > just in theory), we potentia
On Wed, Nov 04, 2015 at 09:28:34AM -0600, Christoph Lameter wrote:
> On Wed, 4 Nov 2015, Catalin Marinas wrote:
>
> > BTW, assuming L1_CACHE_BYTES is 512 (I don't ever see this happening but
> > just in theory), we potentially have the same issue. What would save us
> > is that INDEX_NODE would ma
On Wed, 4 Nov 2015, Catalin Marinas wrote:
> BTW, assuming L1_CACHE_BYTES is 512 (I don't ever see this happening but
> just in theory), we potentially have the same issue. What would save us
> is that INDEX_NODE would match the first "kmalloc-512" cache, so we have
> it pre-populated.
Ok maybe a
On Wed, Nov 04, 2015 at 07:53:50AM -0600, Christoph Lameter wrote:
> On Wed, 4 Nov 2015, Catalin Marinas wrote:
>
> > The simplest option would be to make sure that off slab isn't allowed
> > for caches of KMALLOC_MIN_SIZE or smaller, with the drawback that not
> > only "kmalloc-128" but any other
On Wed, 4 Nov 2015, Catalin Marinas wrote:
> The simplest option would be to make sure that off slab isn't allowed
> for caches of KMALLOC_MIN_SIZE or smaller, with the drawback that not
> only "kmalloc-128" but any other such caches will be on slab.
The reason for an off slab configuration is de
(+ linux-mm)
On Tue, Nov 03, 2015 at 05:33:25PM -0600, Christoph Lameter wrote:
> On Tue, 3 Nov 2015, Catalin Marinas wrote:
> > (cc'ing Jonsoo and Christoph; summary: slab failure with L1_CACHE_BYTES
> > of 128 and sizeof(kmem_cache_node) of 152)
>
> Hmmm... Yes that would mean use the 196 sized
On Tue, 3 Nov 2015, Catalin Marinas wrote:
> (cc'ing Jonsoo and Christoph; summary: slab failure with L1_CACHE_BYTES
> of 128 and sizeof(kmem_cache_node) of 152)
Hmmm... Yes that would mean use the 196 sized kmalloc array which is not a
power of two slab. But the code looks fine to me.
> If I re
On Tue, Nov 03, 2015 at 03:55:29PM +0100, Geert Uytterhoeven wrote:
> On Tue, Nov 3, 2015 at 3:38 PM, Catalin Marinas
> wrote:
> > On Tue, Nov 03, 2015 at 12:05:05PM +, Catalin Marinas wrote:
> >> On Tue, Nov 03, 2015 at 12:07:06PM +0100, Geert Uytterhoeven wrote:
> >> > On Wed, Oct 28, 2015
Hi Catalin,
On Tue, Nov 3, 2015 at 3:38 PM, Catalin Marinas wrote:
> On Tue, Nov 03, 2015 at 12:05:05PM +, Catalin Marinas wrote:
>> On Tue, Nov 03, 2015 at 12:07:06PM +0100, Geert Uytterhoeven wrote:
>> > On Wed, Oct 28, 2015 at 8:09 PM, Catalin Marinas
>> > wrote:
>> > > On Tue, Sep 22, 20
On Tue, Nov 03, 2015 at 12:05:05PM +, Catalin Marinas wrote:
> On Tue, Nov 03, 2015 at 12:07:06PM +0100, Geert Uytterhoeven wrote:
> > On Wed, Oct 28, 2015 at 8:09 PM, Catalin Marinas
> > wrote:
> > > On Tue, Sep 22, 2015 at 07:59:48PM +0200, Robert Richter wrote:
> > >> From: Tirumalesh Chala
On Tue, Nov 03, 2015 at 12:07:06PM +0100, Geert Uytterhoeven wrote:
> On Wed, Oct 28, 2015 at 8:09 PM, Catalin Marinas
> wrote:
> > On Tue, Sep 22, 2015 at 07:59:48PM +0200, Robert Richter wrote:
> >> From: Tirumalesh Chalamarla
> >>
> >> Increase the standard cacheline size to avoid having locks
On Wed, Oct 28, 2015 at 8:09 PM, Catalin Marinas
wrote:
> On Tue, Sep 22, 2015 at 07:59:48PM +0200, Robert Richter wrote:
>> From: Tirumalesh Chalamarla
>>
>> Increase the standard cacheline size to avoid having locks in the same
>> cacheline.
>>
>> Cavium's ThunderX core implements cache lines o
On Tue, Sep 22, 2015 at 07:59:48PM +0200, Robert Richter wrote:
> From: Tirumalesh Chalamarla
>
> Increase the standard cacheline size to avoid having locks in the same
> cacheline.
>
> Cavium's ThunderX core implements cache lines of 128 byte size. With
> current granulare size of 64 bytes (L1_
On Tue, Sep 22, 2015 at 12:59 PM, Robert Richter wrote:
> From: Tirumalesh Chalamarla
>
> Increase the standard cacheline size to avoid having locks in the same
> cacheline.
>
> Cavium's ThunderX core implements cache lines of 128 byte size. With
> current granulare size of 64 bytes (L1_CACHE_SHI
On Sat, Oct 10, 2015 at 12:39:25PM -0500, Timur Tabi wrote:
> On Tue, Sep 22, 2015 at 12:59 PM, Robert Richter wrote:
> >
> > -#define L1_CACHE_SHIFT 6
> > +#define L1_CACHE_SHIFT 7
> > #define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT)
>
> Would it be better if this were a Kco
On Tue, Sep 22, 2015 at 12:59 PM, Robert Richter wrote:
>
> -#define L1_CACHE_SHIFT 6
> +#define L1_CACHE_SHIFT 7
> #define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT)
Would it be better if this were a Kconfig option, like it is on ARM32?
http://lxr.free-electrons.com/source/ar
On 09/25/2015 07:45 AM, Robert Richter wrote:
Will,
On 22.09.15 19:29:02, Will Deacon wrote:
On Tue, Sep 22, 2015 at 06:59:48PM +0100, Robert Richter wrote:
From: Tirumalesh Chalamarla
Increase the standard cacheline size to avoid having locks in the same
cacheline.
Cavium's ThunderX core
Will,
On 22.09.15 19:29:02, Will Deacon wrote:
> On Tue, Sep 22, 2015 at 06:59:48PM +0100, Robert Richter wrote:
> > From: Tirumalesh Chalamarla
> >
> > Increase the standard cacheline size to avoid having locks in the same
> > cacheline.
> >
> > Cavium's ThunderX core implements cache lines of
On Tue, Sep 22, 2015 at 06:59:48PM +0100, Robert Richter wrote:
> From: Tirumalesh Chalamarla
>
> Increase the standard cacheline size to avoid having locks in the same
> cacheline.
>
> Cavium's ThunderX core implements cache lines of 128 byte size. With
> current granulare size of 64 bytes (L1_
From: Tirumalesh Chalamarla
Increase the standard cacheline size to avoid having locks in the same
cacheline.
Cavium's ThunderX core implements cache lines of 128 byte size. With
current granulare size of 64 bytes (L1_CACHE_SHIFT=6) two locks could
share the same cache line leading a performance
27 matches
Mail list logo
