Re: [BUG FIX] Make x86_32 uni-processor Atomic ops, Atomic
From: Robert Hancock
Date: Sun May 24 2009 - 14:59:37 EST
Michael S. Zick wrote:
On Fri May 22 2009, Samuel Thibault wrote:
Michael S. Zick, le Fri 22 May 2009 14:53:39 -0500, a écrit :
Ref: http://developer.intel.com/Assets/PDF/manual/253666.pdf
Manual page: 3-590 PDF page: 638
Summary: Processors prior to P-4 can take an interrupt between
the read cycle and the write cycle. Which is why opcode 0xF0 exists.
Where do you see page 638/639 talking about interrupts? It talks about
multi-processor machines.
No - it talks about "exclusive memory access" - You got bus master DMA
in your test machine? You also have an older than P-4 single processor?
It means that LOCK is required in multi-processor environment to ensure
that an instruction executes atomically WRT memory operations being done
on other CPUs. On a single processor, except for some weird exceptions
(like rep instructions, which can't be LOCKed anyways), instructions are
always atomic with respect to interrupts.
Look people, I just reported what I found from testing -
Please don't shoot the messanger.
If it: "Does not make a difference" then it "Should not make a difference"
but it does, try it yourself. Its safe (if LOCK_PREFIX is in the proper
places) - the machine will ignore the opcode if is recent enough to not
need it - just trust the cpu's micro-code.
What do you mean "recent enough to not need it?" There is no such thing.
On any x86 machine it does something. It will slow things down, and
there is no reason it should be required on uni-processor systems.
Quite likely that's the only effect adding the LOCK prefix is having,
slowing things down, and covering up whatever is causing your issue,
without having anything to do with the root cause.
Mike
Samuel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/