RE: [PATCH 1/3] slub: set a criteria for slub node partial adding

[David Rientjes]

On Fri, 9 Dec 2011, Shi, Alex wrote:

> Of course any testing may have result variation. But it is benchmark 
> accordingly, and there are lot technical to tuning your testing to make 
> its stand division acceptable, like to sync your system in a clear 
> status, to close unnecessary services, to use separate working disks for 
> your testing etc. etc. For this data, like on my SNB-EP machine, (the 
> following data is not stands for Intel, it is just my personal data). 

I always run benchmarks with freshly booted machines and disabling all but 
the most basic and required userspace for my testing environment, I can 
assure you that my comparison of slab and slub on netperf TCP_RR isn't 
because of any noise from userspace.

> 4 times result of hackbench on this patch are 5.59, 5.475, 5.47833, 
> 5.504

I haven't been running hackbench benchmarks, sorry.  I was always under 
the assumption that slub still was slightly better than slab with 
hackbench since that was used as justification for it becoming the default 
allocator and also because Christoph had patches merged recently which 
improved its performance on slub.  I've been speaking only about my 
history with netperf TCP_RR when using slub.

> > Not sure what you're asking me to test, you would like this:
> > 
> > 	{
> > 	        n->nr_partial++;
> > 	-       if (tail == DEACTIVATE_TO_TAIL)
> > 	-               list_add_tail(&page->lru, &n->partial);
> > 	-       else
> > 	-               list_add(&page->lru, &n->partial);
> > 	+       list_add_tail(&page->lru, &n->partial);
> > 	}
> > 
> > with the statistics patch above?  I typically run with CONFIG_SLUB_STATS
> > disabled since it impacts performance so heavily and I'm not sure what
> > information you're looking for with regards to those stats.
> 
> NO, when you collect data, please close SLUB_STAT in kernel config.  
> _to_head statistics collection patch just tell you, I collected the 
> statistics not include add_partial in early_kmem_cache_node_alloc(). And 
> other places of add_partial were covered. Of course, the kernel with 
> statistic can not be used to measure performance. 
> 

Ok, I'll benchmark netperf TCP_RR comparing Linus' latest -git both with 
and without the above change.  It was confusing because you had three 
diffs in your email, I wasn't sure which or combination of which you 
wanted me to try :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/