Re: [PATCH 4/5] kgdb: Use atomic operators which use barriers
From: Linus Torvalds
Date: Fri Apr 02 2010 - 16:11:52 EST
On Fri, 2 Apr 2010, Linus Torvalds wrote:
> But Linux does expect that if some other CPU modifies a memory location,
> then we _will_ see that modification eventually. If the CPU needs help to
> do so, then cpu_relax() needs to do that. Again - this has nothing to do
> with memory barriers. It's just a basic requirement.
Btw, this is not necessarily just limited to cpu_relax() either. The
assumption that we'll eventually see changes to memory is pretty common.
If some architecture doesn't see updates from other CPU's (or maybe DMA)
without extra help, I suspect that it might be a good idea to not just
have IO instructions but also things like 'udelay()' have that "extra
helping sauce" in them.
For the exact same reason: we have drivers that depend on things like
jiffies updates happening automatically, eg:
drivers/scsi/u14-34f.c: while ((jiffies - time) < (10 * HZ) && limit++ < 200000) udelay(100L);
drivers/isdn/hisax/elsa_ser.c- while(timeout-- && cs->hw.elsa.transcnt)
drivers/serial/68328serial.c: while (!(uart->utx.w & UTX_TX_AVAIL)) udelay(5);
where those variables we read may be updated from another CPU taking an
interrupt (or by DMA - I didn't look at how UTX_TX_AVAIL gets set, for
Now, in practice, I suspect the above kind of busy loop is _way_ less
common. It's harder to grep for (I picked 'udelay()' to look for, but
the result is full of noise that does IO etc that would presumably fix
things anyway, so the above two are just random examples of some drivers
basically reading variables in a busy loop).
And for something like ARM, random drivers probably don't much matter. So
I doubt that this udelay() thing is at _all_ as important as cpu_relax()
is, and ARM maintainers can probably happily just ignore it.
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/