linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Wei Yang <richard.weiyang@gmail.com>
To: Christopher Lameter <cl@linux.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Wei Yang <richard.weiyang@gmail.com>,
	penberg@kernel.org, mhocko@kernel.org, linux-mm@kvack.org,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v2] mm/slub: improve performance by skipping checked node in get_any_partial()
Date: Mon, 24 Dec 2018 22:03:22 +0000	[thread overview]
Message-ID: <20181224220322.5z3oyqzrvptttamp@master> (raw)
In-Reply-To: <01000167ce692d0d-ef68fdc8-4c30-40a4-8ca5-afbc3773c075-000000@email.amazonses.com>

On Fri, Dec 21, 2018 at 01:37:38AM +0000, Christopher Lameter wrote:
>On Thu, 20 Dec 2018, Andrew Morton wrote:
>
>>   The result of (get_partial_count / get_partial_try_count):
>>
>>    +----------+----------------+------------+-------------+
>>    |          |       Base     |    Patched |  Improvement|
>>    +----------+----------------+------------+-------------+
>>    |One Node  |       1:3      |    1:0     |      - 100% |
>
>If you have one node then you already searched all your slabs. So we could
>completely skip the get_any_partial() functionality in the non NUMA case
>(if nr_node_ids == 1)
>
>
>>    +----------+----------------+------------+-------------+
>>    |Four Nodes|       1:5.8    |    1:2.5   |      -  56% |
>>    +----------+----------------+------------+-------------+
>
>Hmm.... Ok but that is the extreme slowpath.
>
>>    Each version/system configuration combination has four round kernel
>>    build tests. Take the average result of real to compare.
>>
>>    +----------+----------------+------------+-------------+
>>    |          |       Base     |   Patched  |  Improvement|
>>    +----------+----------------+------------+-------------+
>>    |One Node  |      4m41s     |   4m32s    |     - 4.47% |
>>    +----------+----------------+------------+-------------+
>>    |Four Nodes|      4m45s     |   4m39s    |     - 2.92% |
>>    +----------+----------------+------------+-------------+
>
>3% on the four node case? That means that the slowpath is taken
>frequently. Wonder why?
>
>Can we also see the variability? Since this is a NUMA system there is
>bound to be some indeterminism in those numbers.

Hmm... I rebuilt the kernel and try the experiment again, but found I
can't reproduce this statistics. The data show it is worse than base
line and shakes heavily...

Base                    Patched 
                        
real    5m49.652s       real    8m9.515s
user    19m0.581s       user    17m30.296s
sys     2m31.906s       sys     2m21.445s
                        
real    5m47.145s       real    6m47.437s
user    19m17.445s      user    18m33.461s
sys     2m41.931s       sys     2m43.249s
                        
real    7m2.043s        real    5m38.539s
user    18m11.723s      user    19m40.552s
sys     2m46.443s       sys     2m43.771s
                        
real    5m31.797s       real    12m59.936s
user    19m13.984s      user    15m47.602s
sys     2m34.727s       sys     2m20.385s



















-- 
Wei Yang
Help you, Help me

      parent reply	other threads:[~2018-12-24 22:03 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08  1:12 [PATCH] mm/slub: skip node in case there is no slab to acquire Wei Yang
2018-11-09 20:48 ` Andrew Morton
2018-11-09 23:47   ` Wei Yang
2018-11-13  9:12 ` [PATCH v2] " Wei Yang
2018-11-13 13:17 ` [PATCH] " Michal Hocko
2018-11-13 13:26   ` Wei Yang
2018-11-13 13:34     ` Michal Hocko
2018-11-20  3:31 ` [PATCH v2] mm/slub: improve performance by skipping checked node in get_any_partial() Wei Yang
2018-11-22  3:05   ` Andrew Morton
2018-11-22  9:13     ` Wei Yang
2018-11-22 23:41     ` Wei Yang
2018-11-23 13:39       ` Michal Hocko
2018-11-23 13:49         ` Michal Hocko
2018-11-23 15:27           ` Wei Yang
2018-12-20 22:41   ` Andrew Morton
2018-12-21  0:25     ` Alexander Duyck
2018-12-21  3:29       ` Wei Yang
2018-12-21  1:37     ` Christopher Lameter
2018-12-21  1:37       ` Christopher Lameter
2018-12-21  3:33       ` Wei Yang
2018-12-24 22:03       ` Wei Yang [this message]

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=20181224220322.5z3oyqzrvptttamp@master \
    --to=richard.weiyang@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.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