[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20110215.132702.39199169.davem@davemloft.net>
Date: Tue, 15 Feb 2011 13:27:02 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: simoneau@....uri.edu
Cc: will.newton@...il.com, hpa@...or.com, matt@...sole-pimps.org,
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
From: Will Simoneau <simoneau@....uri.edu>
Date: Tue, 15 Feb 2011 16:11:23 -0500
> Note how the cache and cache coherence protocol are fundamental parts of this
> operation; if these instructions simply bypassed the cache, they *could not*
> work correctly - how do you detect when the underlying memory has been
> modified?
The issue here isn't L2 cache bypassing, it's local L1 cache bypassing.
The chips in question aparently do not consult the local L1 cache on
"ll" instructions.
Therefore you must only ever access such atomic data using "ll"
instructions.
--
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