Re: [Lse-tech] [PATCH] breaking up the pagemap_lru_lock in rmap

[Hubertus F. <fr...@wa...>]

On Mon, Mar 04, 2002 at 07:16:42PM +0100, Andi Kleen wrote:
> > --- linux-2.4.17-rmap/include/linux/mm.h	Thu Feb 14 17:53:17 2002
> > +++ linux-2.4.17-rmap-mjb/include/linux/mm.h	Tue Feb 26 10:34:23 2002
> > @@ -160,6 +160,7 @@
> >  					   protected by pagemap_lru_lock !! */
> >  	unsigned char age;		/* Page aging counter. */
> >  	unsigned char zone;		/* Memory zone the page belongs to. */
> > +	spinlock_t pte_chain_lock;
> >  	struct pte_chain * pte_chain;	/* Reverse pte mapping pointer. */
> >  	struct page **pprev_hash;	/* Complement to *next_hash. */
> >  	struct buffer_head * buffers;	/* Buffer maps us to a disk block. */
> 
> You add a new field to struct page. That seems to be somewhat contraproductive
> with all the recent work to shrink struct page.
> 
> -Andi
> 

Martin, Andy,  

You can get ride of the pte_chain_lock addition and use the following mechanism,
i.e. some simple coloring scheme to cut down on the lock contention and the space
requirements. 

#define NUM_CHAIN_LOCKS_LOG 8   /* (or whatever) */
#define NUM_CHAIN_LOCKS  ( 1<< NUM_CHAIN_LOCKS) 
spinlock_t pte_chain_locks[NUM_CHAIN_LOCKS];

#define pte_chain_lock(page)   spinlock (&pte_chain_locks[(page_number(page) & (NUM_CHAIN_LOCKS - 1)) ] )
#define pte_chain_unlock(page)   spinunlock (&pte_chain_locks[(page_number(page) & (NUM_CHAIN_LOCKS - 1)) ] )

You get the idea (syntax and call are most likely wrong).

Don't know what the right number of LOCKS could/should be.

-- Hubertus