linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: "Shi, Alex" <alex.shi@intel.com>
Cc: Christoph Lameter <cl@linux.com>,
	"penberg@kernel.org" <penberg@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Eric Dumazet <eric.dumazet@gmail.com>
Subject: RE: [PATCH 1/3] slub: set a criteria for slub node partial adding
Date: Tue, 13 Dec 2011 17:38:43 -0800 (PST)	[thread overview]
Message-ID: <alpine.DEB.2.00.1112131734070.8593@chino.kir.corp.google.com> (raw)
In-Reply-To: <6E3BC7F7C9A4BF4286DD4C043110F30B67236EED18@shsmsx502.ccr.corp.intel.com>

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, 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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-12-14  1:38 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-02  8:23 Alex Shi
2011-12-02  8:23 ` [PATCH 2/3] slub: remove unnecessary statistics, deactivate_to_head/tail Alex Shi
2011-12-02  8:23   ` [PATCH 3/3] slub: fill per cpu partial only when free objects larger than one quarter Alex Shi
2011-12-02 14:44   ` [PATCH 2/3] slub: remove unnecessary statistics, deactivate_to_head/tail Christoph Lameter
2011-12-06 21:08   ` David Rientjes
2011-12-02 11:36 ` [PATCH 1/3] slub: set a criteria for slub node partial adding Eric Dumazet
2011-12-02 20:02   ` Christoph Lameter
2011-12-05  2:21     ` Shaohua Li
2011-12-05 10:01     ` Alex,Shi
2011-12-05  3:28   ` Alex,Shi
2011-12-02 14:43 ` Christoph Lameter
2011-12-05  9:22   ` Alex,Shi
2011-12-06 21:06     ` David Rientjes
2011-12-07  5:11       ` Shaohua Li
2011-12-07  7:28         ` David Rientjes
2011-12-12  2:43           ` Shaohua Li
2011-12-12  4:14             ` Alex,Shi
2011-12-12  4:35               ` Shaohua Li
2011-12-12  4:25                 ` Alex,Shi
2011-12-12  4:48                   ` Shaohua Li
2011-12-12  6:17                     ` Alex,Shi
2011-12-12  6:09             ` Eric Dumazet
2011-12-14  1:29             ` David Rientjes
2011-12-14  2:43               ` Shaohua Li
2011-12-14  2:38                 ` David Rientjes
2011-12-09  8:30   ` Alex,Shi
2011-12-09 10:10     ` David Rientjes
2011-12-09 13:40       ` Shi, Alex
2011-12-14  1:38         ` David Rientjes [this message]
2011-12-14  2:36           ` David Rientjes
2011-12-14  6:06             ` Alex,Shi
2011-12-14  6:44               ` Eric Dumazet
2011-12-14  6:47                 ` Pekka Enberg
2011-12-14 14:53                   ` Christoph Lameter
2011-12-14  6:56                 ` Alex,Shi
2011-12-14 14:59                   ` Christoph Lameter
2011-12-14 17:33                     ` Eric Dumazet
2011-12-14 18:26                       ` Christoph Lameter
2011-12-13 13:01       ` Shi, Alex

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=alpine.DEB.2.00.1112131734070.8593@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=alex.shi@intel.com \
    --cc=cl@linux.com \
    --cc=eric.dumazet@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=penberg@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox