[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTikVB6Vf5W-KACdLJOz=FmtU4syQ4z1EWmjunB5o@mail.gmail.com>
Date: Tue, 15 Feb 2011 14:04:08 +0000
From: Will Newton <will.newton@...il.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Matt Fleming <matt@...sole-pimps.org>,
David Miller <davem@...emloft.net>, rostedt@...dmis.org,
peterz@...radead.org, jbaron@...hat.com,
mathieu.desnoyers@...ymtl.ca, mingo@...e.hu, tglx@...utronix.de,
andi@...stfloor.org, roland@...hat.com, rth@...hat.com,
masami.hiramatsu.pt@...achi.com, fweisbec@...il.com,
avi@...hat.com, sam@...nborg.org, ddaney@...iumnetworks.com,
michael@...erman.id.au, linux-kernel@...r.kernel.org,
vapier@...too.org, cmetcalf@...era.com, dhowells@...hat.com,
schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
benh@...nel.crashing.org
Subject: Re: [PATCH 0/2] jump label: 2.6.38 updates
On Tue, Feb 15, 2011 at 1:31 PM, H. Peter Anvin <hpa@...or.com> wrote:
> On 02/15/2011 03:01 AM, Will Newton wrote:
>>
>> The CPU in question has two sets of instructions:
>>
>> load/store - these go via the cache (write through)
>> ll/sc - these operate literally as if there is no cache (they do not
>> hit on read or write)
>>
>> This may or may not be a sensible way to architect a CPU, but I think
>> it is possible to make it work. Making it work efficiently is more of
>> a challenge.
>>
>
> a) What "CPU in question" is this?
http://imgtec.com/meta/meta-technology.asp
> b) Why should we let this particular insane CPU slow ALL OTHER CPUs down?
I didn't propose we do that. I brought it up just to make people aware
that there are these odd architectures out there, and indeed it turns
out Blackfin has some superficially similar issues.
--
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