On Saturday 04 March 2006 11:58, you wrote: > Linus Torvalds writes: > > > PPC has an absolutely _horrible_ memory ordering implementation, as far as > > I can tell. The thing is broken. I think it's just implementation > > breakage, not anything really fundamental, but the fact that their write > > barriers are expensive is a big sign that they are doing something bad. > > An smp_wmb() is just an eieio on PPC, which is pretty cheap. I made > wmb() be a sync though, because it seemed that there were drivers that > expected wmb() to provide an ordering between a write to memory and a > write to an MMIO register. If that is a bogus assumption then we > could make wmb() lighter-weight (after auditing all the drivers we're > interested in, of course, ...). In the bcm43xx driver there is code which looks like the following: /* Write some coherent DMA memory */ wmb(); /* Write MMIO, which depends on the DMA memory * write to be finished. */ Are the assumptions in this code correct? Is wmb() the correct thing to do here? I heavily tested this code on PPC UP and did not see any anormaly, yet. -- Greetings Michael.
Attachment:
pgpnoMJHNLQGI.pgp
Description: PGP signature
- References:
- Memory barriers and spin_unlock safety
- From: David Howells <[email protected]>
- Re: Memory barriers and spin_unlock safety
- From: Linus Torvalds <[email protected]>
- Re: Memory barriers and spin_unlock safety
- From: Paul Mackerras <[email protected]>
- Memory barriers and spin_unlock safety
- Prev by Date: Re: Debian Installer - boot floppies
- Next by Date: Re: [PATCH 0/8] Intel I/O Acceleration Technology (I/OAT)
- Previous by thread: Re: Memory barriers and spin_unlock safety
- Next by thread: Re: Memory barriers and spin_unlock safety
- Index(es):
 |