lkml.org 
[lkml]   [2010]   [Apr]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 4/5] kgdb: Use atomic operators which use barriers


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);

or

drivers/isdn/hisax/elsa_ser.c- while(timeout-- && cs->hw.elsa.transcnt)
drivers/isdn/hisax/elsa_ser.c: udelay(1000);

or

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
example).

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.

Linus


\
 
 \ /
  Last update: 2010-04-02 22:13    [W:0.174 / U:0.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site