[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0711010555390.27666@schroedinger.engr.sgi.com>
Date: Thu, 1 Nov 2007 05:57:12 -0700 (PDT)
From: Christoph Lameter <clameter@....com>
To: Eric Dumazet <dada1@...mosbay.com>
cc: akpm@...ux-foundation.org, linux-arch@...r.kernel.org,
linux-kernel@...r.kernel.org,
Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
Pekka Enberg <penberg@...helsinki.fi>
Subject: Re: [patch 0/7] [RFC] SLUB: Improve allocpercpu to reduce per cpu
access overhead
On Thu, 1 Nov 2007, Eric Dumazet wrote:
> I think this question already came in the past and Linus already answered it,
> but I again ask it. What about VM games with modern cpus (64 bits arches)
>
> Say we reserve on x86_64 a really huge (2^32 bytes) area, and change VM layout
> so that each cpu maps its own per_cpu area on this area, so that the local
> per_cpu data sits in the same virtual address on each cpu. Then we dont need a
> segment prefix nor adding a 'per_cpu offset'. No need to write special asm
> functions to read/write/increment a per_cpu data and gcc could use normal
> rules for optimizations.
>
> We only would need adding "per_cpu offset" to get data for a given cpu.
That is basically what IA64 is doing but it not usable because you would
have addresses that mean different things on different cpus. List head
for example require back pointers. If you put a listhead into such a per
cpu area then you may corrupt another cpus per cpu area.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists