From: Steven Whitehouse <swhiteho@redhat.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Nick Piggin <npiggin@suse.de>
Subject: Re: vmalloc performance
Date: Fri, 16 Apr 2010 15:10:56 +0100 [thread overview]
Message-ID: <1271427056.7196.163.camel@localhost.localdomain> (raw)
In-Reply-To: <1271350270.2013.29.camel@barrios-desktop>
Hi,
On Fri, 2010-04-16 at 01:51 +0900, Minchan Kim wrote:
[snip]
> Thanks for the explanation. It seems to be real issue.
>
> I tested to see effect with flush during rb tree search.
>
> Before I applied your patch, the time is 50300661 us.
> After your patch, 11569357 us.
> After my debug patch, 6104875 us.
>
> I tested it as changing threshold value.
>
> threshold time
> 1000 13892809
> 500 9062110
> 200 6714172
> 100 6104875
> 50 6758316
>
My results show:
threshold time
100000 139309948
1000 13555878
500 10069801
200 7813667
100 18523172
50 18546256
> And perf shows smp_call_function is very low percentage.
>
> In my cases, 100 is best.
>
Looks like 200 for me.
I think you meant to use the non _minmax version of proc_dointvec too?
Although it doesn't make any difference for this basic test.
The original reporter also has 8 cpu cores I've discovered. In his case
divided by 4 cpus where as mine are divided by 2 cpus, but I think that
makes no real difference in this case.
I'll try and get some further test results ready shortly. Many thanks
for all your efforts in tracking this down,
Steve.
next prev parent reply other threads:[~2010-04-16 14:11 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-12 16:27 vmalloc performance Steven Whitehouse
2010-04-14 12:49 ` Steven Whitehouse
2010-04-14 14:24 ` Steven Whitehouse
2010-04-14 15:12 ` Minchan Kim
2010-04-14 15:13 ` Minchan Kim
2010-04-14 16:35 ` Minchan Kim
2010-04-15 8:33 ` Steven Whitehouse
2010-04-15 16:51 ` Minchan Kim
2010-04-16 14:10 ` Steven Whitehouse [this message]
2010-04-18 15:14 ` Minchan Kim
2010-04-19 12:58 ` Steven Whitehouse
2010-04-19 14:12 ` Minchan Kim
2010-04-29 13:43 ` Steven Whitehouse
2010-05-02 17:29 ` [PATCH] cache last free vmap_area to avoid restarting beginning Minchan Kim
2010-05-05 12:48 ` Steven Whitehouse
2010-05-05 16:16 ` Nick Piggin
2010-05-17 12:42 ` Steven Whitehouse
2010-05-18 13:44 ` Steven Whitehouse
2010-05-19 13:54 ` Steven Whitehouse
2010-05-19 13:56 ` Nick Piggin
2010-05-25 8:43 ` Nick Piggin
2010-05-25 15:00 ` Minchan Kim
2010-05-25 15:48 ` Steven Whitehouse
2010-05-22 9:53 ` Minchan Kim
2010-05-24 6:23 ` Nick Piggin
2010-04-19 13:38 ` vmalloc performance Nick Piggin
2010-04-19 14:09 ` Minchan Kim
2010-04-16 6:12 ` Nick Piggin
2010-04-16 7:20 ` Minchan Kim
2010-04-16 8:50 ` Steven Whitehouse
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=1271427056.7196.163.camel@localhost.localdomain \
--to=swhiteho@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan.kim@gmail.com \
--cc=npiggin@suse.de \
/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).