From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier To: Linus Torvalds Cc: Andrea Arcangeli , "David S. Miller" , Ingo Molnar , linux-kernel@vger.kernel.org, gcc@gcc.gnu.org Subject: Re: spin_lock forgets to clobber memory and other smp fixes [was Re: [patch] waitqueue optimization, 2.4.0-test7] Date: Thu, 07 Sep 2000 10:11:00 -0000 Message-id: <20000907191127.F22962@pcep-jamie.cern.ch> References: <20000907183941.A22962@pcep-jamie.cern.ch> X-SW-Source: 2000-09/msg00163.html Linus Torvalds wrote: > Nope. "memory" fills that role too. Remember: "memory" doesn't actually > say "this clobbers all memory". That would be silly: an asm that just > wipes all memory would not be a very useful asm (or rather, it would have > just _one_ use: "execve()"). So "memory" really says that the asm clobbers > _some_ memory. > > Which in turn means that the code scheduler has to synchronize all memory > accesses around it - as if the asm was reading all memory. Because if the > scheduler would move a store to after the asm, it would give the wrong > results if the asm happened to clobber _that_ memory. And the scheduler > obviously cannot just drop the store ("Oh, the asm will clobber this > anyway"), because it doesn't know which memory regions get clobbered. There are other reasons why stores can be eliminated, and "memory" does not prevent those. Example: you have two stores to the same address. An "asm" with "memory" is in between the stores. The first store can still be dropped, even though we don't know _which_ memory the "memory" clobbers. Now, "memory" may well mean "this asm is considered to read some memory and clobber some memory". But that's not what the manual says, and it would be inconsistent with other kinds of clobber. > Now, the fact that the "memory" clobber also seems to clobber local > variables is a bug, I think. If you are thinking of my examples, "memory" doesn't clobber local variables. It does affect the scheduling of reads from general memory into a local variable. -- Jamie