Re: [PATCH 4/4] Slab Reclaim logic

[Christoph Lameter <clameter@sgi.com>]

On Thu, 22 Jun 2006, Pekka J Enberg wrote:

> > @@ -298,6 +299,7 @@ struct kmem_list3 {
> >  	struct array_cache **alien;	/* on other nodes */
> >  	unsigned long next_reap;	/* updated without locking */
> >  	int free_touched;		/* updated without locking */
> > +	atomic_t reclaim;			/* Reclaim in progress */
> >  };
> 
> Hmm, we don't need 'marker' and 'reclaim' if SLAB_RECLAIM is not set, 
> right?  I don't think we want to bloat struct slab and struct kmem_list3 
> for everyone.  What's marker used for?  Why can't we just take the list 
> lock instead of 'reclaim'?

Yes we do not need those if SLAB_RECLAIM is not set.

We only take the list lock for getting at slab addresses. We want slab 
operations to continue wile reclaim is in progress.

The marker does not cost anything on ia64 due to structure alignment. We 
need to have some way (in the absense of taking the list lock) to know 
when we have reclaimed all slabs.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/