All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Andrew Morton <akpm@digeo.com>
Cc: davem@redhat.com, shemminger@osdl.org, rmk@arm.linux.org.uk,
	ak@muc.de, davidm@napali.hpl.hp.com, anton@samba.org,
	linux-mm@kvack.org, rth@twiddle.net
Subject: Re: Linus rollup
Date: Thu, 30 Jan 2003 02:54:27 +0100	[thread overview]
Message-ID: <20030130015427.GU1237@dualathlon.random> (raw)
In-Reply-To: <20030129180054.03ac0d48.akpm@digeo.com>

On Wed, Jan 29, 2003 at 06:00:54PM -0800, Andrew Morton wrote:
> Andrea Arcangeli <andrea@suse.de> wrote:
> >
> > On Wed, Jan 29, 2003 at 05:27:43PM -0800, Andrew Morton wrote:
> > > @@ -82,11 +85,12 @@ static inline int fr_write_trylock(frloc
> > >  
> > >  	if (ret) {
> > >  		++rw->pre_sequence;
> > > -		wmb();
> > > +		mb();
> > >  	}
> > 
> > this isn't needed
> > 
> > 
> > if we hold the spinlock, the serialized memory can't be change under us,
> > so there's no need to put a read barrier, we only care that pre_sequence
> > is visible before the chagnes are visible and before post_sequence is
> > visible, hence only wmb() (after spin_lock and pre_sequence++) is
> > needed there and only rmb() is needed in the read-side.
> > 
> 
> OK, thanks muchly.
> 
> Lots more updates.  Here's the version which I currently have.  Looks like
> fr_write_lock() and fr_write_unlock() need to be switched back to rmb()?

you certainly mean wmb() not rmb(), right? If yes, then yes.

I actually didn't notice the write_begin/end, not sure who could need
them, I would suggest removing them, rather than to revert the mb()
there too.

> 
> 
> 
> #ifndef __LINUX_FRLOCK_H
> #define __LINUX_FRLOCK_H
> 
> /*
>  * Fast read-write spinlocks.
>  *
>  * Fast reader/writer locks without starving writers. This type of
>  * lock for data where the reader wants a consitent set of information
>  * and is willing to retry if the information changes.  Readers never
>  * block but they may have to retry if a writer is in
>  * progress. Writers do not wait for readers. 
>  *
>  * Generalization on sequence variables used for gettimeofday on x86-64 
>  * by Andrea Arcangeli
>  *
>  * This is not as cache friendly as brlock. Also, this will not work
>  * for data that contains pointers, because any writer could
>  * invalidate a pointer that a reader was following.
>  *
>  * Expected reader usage:
>  * 	do {
>  *	    seq = fr_read_begin();
>  * 	...
>  *      } while (seq != fr_read_end());
>  *
>  * On non-SMP the spin locks disappear but the writer still needs
>  * to increment the sequence variables because an interrupt routine could
>  * change the state of the data.
>  */
> 
> #include <linux/config.h>
> #include <linux/spinlock.h>
> #include <linux/preempt.h>
> 
> typedef struct {
> 	unsigned pre_sequence;
> 	unsigned post_sequence;
> 	spinlock_t lock;
> } frlock_t;
> 
> /*
>  * These macros triggered gcc-3.x compile-time problems.  We think these are
>  * OK now.  Be cautious.
>  */
> #define FR_LOCK_UNLOCKED { 0, 0, SPIN_LOCK_UNLOCKED }
> #define frlock_init(x)	do { *(x) = (frlock_t) FR_LOCK_UNLOCKED; } while (0)
> 
> /* Update sequence count only
>  * Assumes caller is doing own mutual exclusion with other lock
>  * or semaphore.
>  */
> static inline void fr_write_begin(frlock_t *rw)
> {
> 	preempt_disable();
> 	rw->pre_sequence++;
> 	mb();
> }
> 
> static inline void fr_write_end(frlock_t *rw)
> {
> 	mb();
> 	rw->post_sequence++;
> 	BUG_ON(rw->post_sequence != rw->pre_sequence);
> 	preempt_enable();
> }
> 
> /* Lock out other writers and update the count.
>  * Acts like a normal spin_lock/unlock.
>  */
> static inline void fr_write_lock(frlock_t *rw)
> {
> 	spin_lock(&rw->lock);
> 	rw->pre_sequence++;
> 	mb();
> }	
> 
> static inline void fr_write_unlock(frlock_t *rw) 
> {
> 	mb();
> 	rw->post_sequence++;
> 	spin_unlock(&rw->lock);
> }
> 
> static inline int fr_write_trylock(frlock_t *rw)
> {
> 	int ret = spin_trylock(&rw->lock);
> 
> 	if (ret) {
> 		++rw->pre_sequence;
> 		wmb();
> 	}
> 	return ret;
> }
> 
> static inline unsigned fr_read_begin(const frlock_t *rw) 
> {
> 	unsigned ret = rw->post_sequence;
> 	rmb();
> 	return ret;
> 	
> }
> 
> /* End of reader calculation -- fetch last writer start token */
> static inline unsigned fr_read_end(const frlock_t *rw)
> {
> 	rmb();
> 	return rw->pre_sequence;
> }
> 
> /*
>  * Possible sw/hw IRQ protected versions of the interfaces.
>  */
> #define fr_write_lock_irqsave(lock, flags)				\
> 	do { local_irq_save(flags);	fr_write_lock(lock); } while (0)
> #define fr_write_lock_irq(lock)						\
> 	do { local_irq_disable();	fr_write_lock(lock); } while (0)
> #define fr_write_lock_bh(lock)						\
>         do { local_bh_disable();	fr_write_lock(lock); } while (0)
> 
> #define fr_write_unlock_irqrestore(lock, flags)				\
> 	do { fr_write_unlock(lock); local_irq_restore(flags); } while(0)
> #define fr_write_unlock_irq(lock)					\
> 	do { fr_write_unlock(lock); local_irq_enable(); } while(0)
> #define fr_write_unlock_bh(lock)					\
> 	do { fr_write_unlock(lock); local_bh_enable(); } while(0)
> 
> #define fr_read_begin_irqsave(lock, flags)				\
> 	({ local_irq_save(flags);	fr_read_begin(lock); })
> 
> #define fr_read_end_irqrestore(lock, flags)				\
> 	({	unsigned ret = fr_read_end(lock);			\
> 		local_irq_save(flags);					\
> 		ret;							\
> 	})
> 
> #endif /* __LINUX_FRLOCK_H */
> 


Andrea
--
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/

  parent reply	other threads:[~2003-01-30  1:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-01-29  6:07 Linus rollup Andrew Morton
2003-01-29  6:53 ` David Mosberger
2003-01-29  7:25 ` David S. Miller
2003-01-29  9:33 ` Andrew Morton
2003-01-29  9:35   ` David S. Miller
2003-01-29  9:54 ` Anton Blanchard
2003-01-29  9:59 ` Russell King
2003-01-29  9:51   ` David S. Miller
2003-01-29 10:26     ` Andrew Morton
2003-01-29 22:35       ` Stephen Hemminger
2003-01-29 23:12         ` Andrew Morton
2003-01-30  0:30           ` David S. Miller
2003-01-30  1:27             ` Andrew Morton
2003-01-30  1:24               ` Andi Kleen
2003-01-30  2:01                 ` Andrew Morton
2003-01-30  1:35               ` Andrea Arcangeli
2003-01-30  2:00                 ` Andrew Morton
2003-01-30  1:50                   ` Jeff Garzik
2003-01-30  2:03                     ` Andrea Arcangeli
2003-01-30 17:09                       ` Stephen Hemminger
2003-01-30 17:15                         ` Randy.Dunlap
2003-01-30 17:25                           ` Andi Kleen
2003-01-30 17:23                             ` Randy.Dunlap
2003-01-30  1:52                   ` Richard Henderson
2003-01-30  2:06                     ` Andrea Arcangeli
2003-01-30  1:54                   ` Andrea Arcangeli [this message]
2003-01-30  2:19                     ` Andrew Morton
2003-01-30 17:37                     ` Stephen Hemminger
2003-01-30 17:50                       ` Andrea Arcangeli
2003-01-30  2:00                   ` Richard Henderson
2003-01-30  0:46         ` Andrea Arcangeli
2003-01-30  0:43       ` Andrea Arcangeli
2003-01-29 10:16   ` Andrew Morton
2003-01-29 17:04   ` David Mosberger
2003-01-29 17:25     ` Russell King
2003-01-29 19:05       ` David Mosberger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030130015427.GU1237@dualathlon.random \
    --to=andrea@suse.de \
    --cc=ak@muc.de \
    --cc=akpm@digeo.com \
    --cc=anton@samba.org \
    --cc=davem@redhat.com \
    --cc=davidm@napali.hpl.hp.com \
    --cc=linux-mm@kvack.org \
    --cc=rmk@arm.linux.org.uk \
    --cc=rth@twiddle.net \
    --cc=shemminger@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.