On Llu, 2005-01-03 at 22:05, Alan Stern wrote:
> On Mon, 3 Jan 2005, Alan Cox wrote:
> Alan, I respect your judgement and your advice. If after looking more
> closely at this you still think the code should be changed to use barriers
> instead, I will do it.
>
> But first you should read my reply to Pete, and you should see how the
> driver is affected. You will be hard-pressed to find any spots where the
> "volatile" causes abominable code generation.
In terms of bad code, it will make uhci_show_qh keep reloading from
memory for each & UHCI_ foo that it looks at. uhci_insert_tds_in_qh
cases the objects so will end up using non volatile anyway. uhci-hcd.c
seems not to be too affected
None of this helps much when you are worried about races agains the host
controller however because the processors will speculate and volatile is
only a compile ordering tool. Even if volatile forces the ordering of
writes in the assembler, the processors like the PPC ones will then
change their minds unless you coax them nicely with rmb/wmb and friends.
Another little nasty is that operations like *x |= 1 on a volatile
will still generate
reg = *x
reg |= 1
*x = reg
on many processors, which is why we ended up with functionality like
set_bit()
Dave asked about speculation. The kind of things the processors will do
with main memory references (and sometimes other references but not
readl/writel type) is to issue them out of order, or "just in case".
Even with volatiles everywhere code like
code = *v;
if(*a == 1)
ret = *b;
else
ret = *c;
can come out of the processor ordered as
read *b
read *c
read *a
read *v
When you use the barrier functions the kernel provides either
explicitly, or implicitly in the spinlock functions, those barriers are
true CPU level barriers (rmb/wmb). volatile is "dont cache", the
barriers are -ordering-, and in almost all cases what you care about is
ordering as in the example compilation problem posted.
I make the comments based on several experiences where we added volatile
and then eventually ended up fixing it properly. I certainly can't
guarantee I am right I'm just voicing and opinion.
Alan
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
