[lkml]   [2008]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] alloc_percpu() fails to allocate percpu data
Andrew Morton a écrit :
> On Wed, 27 Feb 2008 11:59:32 -0800 (PST)
> Christoph Lameter <> wrote:
>> Any decision made on what to do about this one? Mike or I can
>> repost the per cpu allocator against mm? The fix by Eric could be used
>> in the interim for 2.6.24?
> I suppose I'll merge Eric's patch when I've tested it fully (well, as fully
> as I test stuff).
> It'd be nice to get that cache_line_size()/L1_CACHE_BYTES/L1_CACHE_ALIGN()
> mess sorted out. If it's a mess - I _think_ it is?

Just coming back from hollidays, sorry for the delay.

I can provide a patch so that L1_CACHE_BYTES is not anymore a compile time
constant if you want, but I am not sure it is worth the trouble ? (and this
certainly not 2.6.{24|25} stuff :) )

Current situation :

L1_CACHE_BYTES is known at compile time, and can be quite large (128 bytes),
while cache_line_size() gives the real cache line size selected at boot time
given the hardware capabilities.

If L1_CACHE_BYTES is not anymore a constant, compiler will also uses plain
divides to compute L1_CACHE_ALIGN()

Maybe uses of L1_CACHE_ALIGN() in fastpath would 'force' us to not only
declare a cache_line_size() but also a cache_line_size_{mask|shift}() so that
x86 could use :

#define L1_CACHE_ALIGN(x) ((((x)+cache_line_mask())) >> cache_line_shift())

#define L1_CACHE_BYTES (cache_line_size())

But I am not sure we want to play these games (we must also make sure nothing
in the tree wants a constant L1_CACHE_BYTES and replace by SMP_CACHE_BYTES)

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2008-03-01 14:57    [W:0.064 / U:95.520 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site