[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <487525B3.90904@sgi.com>
Date: Wed, 09 Jul 2008 13:55:15 -0700
From: Mike Travis <travis@....com>
To: Ingo Molnar <mingo@...e.hu>
CC: Jeremy Fitzhardinge <jeremy@...p.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"H. Peter Anvin" <hpa@...or.com>,
Christoph Lameter <cl@...ux-foundation.org>,
Jack Steiner <steiner@....com>, linux-kernel@...r.kernel.org
Subject: Re: [RFC 00/15] x86_64: Optimize percpu accesses
Ingo Molnar wrote:
> * Mike Travis <travis@....com> wrote:
>
>> * x86_64: Rebase per cpu variables to zero
>>
>> Take advantage of the zero-based per cpu area provided above. Then
>> we can directly use the x86_32 percpu operations. x86_32 offsets
>> %fs by __per_cpu_start. x86_64 has %gs pointing directly to the
>> pda and the per cpu area thereby allowing access to the pda with
>> the x86_64 pda operations and access to the per cpu variables
>> using x86_32 percpu operations.
>
> hm, have the binutils (or gcc) problems with this been resolved?
>
> If common binutils versions miscompile the kernel with this feature then
> i guess we cannot just unconditionally enable it. (My hope is that it's
> not necessarily a binutils bug but some broken assumption of the kernel
> somewhere.)
>
> Ingo
Currently I'm using gcc-4.2.4. Which are you using?
I labeled it "RFC" as it does not quite work without THREAD_ORDER bumped to 2.
And I believe the stack overflow is happening because of some interrupt
routine as it does not happen on our simulator.
After that is taken care of, I'll start regression testing earlier compilers.
I think someone mentioned that gcc-2.something was the minimum required...?
Thanks,
Mike
--
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