[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D5A8021.2060001@zytor.com>
Date: Tue, 15 Feb 2011 05:31:13 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Will Newton <will.newton@...il.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 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?
b) Why should we let this particular insane CPU slow ALL OTHER CPUs down?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
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