From: "Alex,Shi" <alex.shi@intel.com>
To: Christoph Lameter <cl@linux.com>, David Rientjes <rientjes@google.com>
Cc: "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: Fri, 09 Dec 2011 16:30:02 +0800 [thread overview]
Message-ID: <1323419402.16790.6105.camel@debian> (raw)
In-Reply-To: <alpine.DEB.2.00.1112020842280.10975@router.home>
On Fri, 2011-12-02 at 22:43 +0800, Christoph Lameter wrote:
> On Fri, 2 Dec 2011, Alex Shi wrote:
>
> > From: Alex Shi <alexs@intel.com>
> >
> > Times performance regression were due to slub add to node partial head
> > or tail. That inspired me to do tunning on the node partial adding, to
> > set a criteria for head or tail position selection when do partial
> > adding.
> > My experiment show, when used objects is less than 1/4 total objects
> > of slub performance will get about 1.5% improvement on netperf loopback
> > testing with 2048 clients, wherever on our 4 or 2 sockets platforms,
> > includes sandbridge or core2.
>
> The number of free objects in a slab may have nothing to do with cache
> hotness of all objects in the slab. You can only be sure that one object
> (the one that was freed) is cache hot. Netperf may use them in sequence
> and therefore you are likely to get series of frees on the same slab
> page. How are other benchmarks affected by this change?
I did some experiments on add_partial judgment against rc4, like to put
the slub into node partial head or tail according to free objects, or
like Eric's suggest to combine the external parameter, like below:
n->nr_partial++;
- if (tail == DEACTIVATE_TO_TAIL)
+ if (tail == DEACTIVATE_TO_TAIL ||
+ page->inuse > page->objects /2)
list_add_tail(&page->lru, &n->partial);
else
list_add(&page->lru, &n->partial);
But the result is out of my expectation before. Now we set all of slub
into the tail of node partial, we get the best performance, even it is
just a slight improvement.
{
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);
}
This change can bring about 2% improvement on our WSM-ep machine, and 1%
improvement on our SNB-ep and NHM-ex machine. and no clear effect for
core2 machine. on hackbench process benchmark.
./hackbench 100 process 2000
For multiple clients loopback netperf, only a suspicious 1% improvement
on our 2 sockets machine. and others have no clear effect.
But, when I check the deactivate_to_head/to_tail statistics on original
code, the to_head is just hundreds or thousands times, while to_tail is
called about teens millions times.
David, could you like to try above change? move all slub to partial
tail.
add_partial statistics collection patch:
---
commit 1ff731282acb521f3a7c2e3fb94d35ec4d0ff07e
Author: Alex Shi <alex.shi@intel.com>
Date: Fri Dec 9 18:12:14 2011 +0800
slub: statistics collection for add_partial
diff --git a/mm/slub.c b/mm/slub.c
index 5843846..a2b1143 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1904,10 +1904,11 @@ static void unfreeze_partials(struct kmem_cache *s)
if (l != m) {
if (l == M_PARTIAL)
remove_partial(n, page);
- else
+ else {
add_partial(n, page,
DEACTIVATE_TO_TAIL);
-
+ stat(s, DEACTIVATE_TO_TAIL);
+ }
l = m;
}
@@ -2480,6 +2481,7 @@ static void __slab_free(struct kmem_cache *s, struct page *page,
remove_full(s, page);
add_partial(n, page, DEACTIVATE_TO_TAIL);
stat(s, FREE_ADD_PARTIAL);
+ stat(s, DEACTIVATE_TO_TAIL);
}
}
spin_unlock_irqrestore(&n->list_lock, flags);
--
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>
next prev parent reply other threads:[~2011-12-09 8:32 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-02 8:23 [PATCH 1/3] slub: set a criteria for slub node partial adding 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 [this message]
2011-12-09 10:10 ` David Rientjes
2011-12-09 13:40 ` Shi, Alex
2011-12-14 1:38 ` David Rientjes
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=1323419402.16790.6105.camel@debian \
--to=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 \
--cc=rientjes@google.com \
/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;
as well as URLs for NNTP newsgroup(s).