[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m14p6xph85.fsf@frodo.ebiederm.org>
Date: Thu, 10 Jul 2008 14:22:18 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Christoph Lameter <cl@...ux-foundation.org>
Cc: Jeremy Fitzhardinge <jeremy@...p.org>,
"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
Mike Travis <travis@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jack Steiner <steiner@....com>, linux-kernel@...r.kernel.org,
Arjan van de Ven <arjan@...radead.org>
Subject: Re: [RFC 00/15] x86_64: Optimize percpu accesses
Christoph Lameter <cl@...ux-foundation.org> writes:
> Jeremy Fitzhardinge wrote:
>
>> Percpu on i386 hasn't been a point of discussion. It works fine, and
>> has been working fine for a long time. The same mechanism would work
>> fine on x86-64. Its only "issue" is that it doesn't support the broken
>> gcc abi for stack-protector.
>
> Well that is one thing and then the scaling issues, and the support of the new
> cpu allocator, new arch independent cpu operations etc.
>
>> The problem is all zero-based percpu on x86-64.
>
> The zero based stuff will enable a lot of things. Please have a look at the
> cpu_alloc patchsets.
Christoph again. The reason we are balking at the zero based percpu
area is NOT because it is zero based. It is because systems with it
patched in don't work reliably.
The bottom line is if the tools don't support a clever idea we can't use it.
Hopefully the problem can be root caused and we can use a zero based percpu area.
There are several ways we can achieve that.
Further any design that depends on a zero based percpu can work with a contiguous percpu
with an offset so we should not be breaking whatever design you have for the percpu
allocator.
Eric
--
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