Messages in this thread | | | Date | Thu, 22 Jun 2006 22:46:12 +0300 (EEST) | From | Pekka J Enberg <> | Subject | Re: [PATCH 4/4] Slab Reclaim logic |
| |
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 */ > > > };
On Thu, 22 Jun 2006, Christoph Lameter wrote: > 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.
Not everyone is IA-64. The slab allocator is already pretty memory hungry so lets try not to make it any worse, ok?
Pekka - 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/
| |