Re: smp_rmb in mm/memory.c in 2.6.10

[Kanoj Sarcar <kanojsarcar@yahoo.com>]

--- William Lee Irwin III <wli@holomorphy.com> wrote:

> On Thu, Jan 13, 2005 at 12:26:42PM -0800, Kanoj
> Sarcar wrote:
> > The second question is that even though
> truncate_count
> > is declared atomic (ie probably volatile on most
> > architectures), that does not make gcc guarantee
> > anything in terms of ordering, right?
> > Finally, does anyone really believe that a
> smp_rmb()
> > is required in step 2? My logic is that nopage()
> is
> > guaranteed to grab/release (spin)locks etc as part
> of
> > its processing, and that would force the snapshots
> of
> > truncate_count to be properly ordered.
> 
> spin_unlock() does not imply a memory barrier. e.g.
> on ia32 it's
> not even an atomic operation.

In include/asm-i386/spinlock.h, spin_unlock_string has
a "xchgb" (in case its required). That should be
enough  of a barrier for the hardware, no? 

Thanks.

Kanoj

> 
> 
> -- wli
> --
> To unsubscribe, send a message with 'unsubscribe
> linux-mm' in
> the body to majordomo@kvack.org.  For more info on
> Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"aart@kvack.org">
> aart@kvack.org </a>
> 



		
__________________________________ 
Do you Yahoo!? 
Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>