From: Nick Piggin <nickpiggin@yahoo.com.au>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: "'Ingo Molnar'" <mingo@redhat.com>,
linux-kernel@vger.kernel.org, "'Andrew Morton'" <akpm@osdl.org>
Subject: Re: Default cache_hot_time value back to 10ms
Date: Wed, 06 Oct 2004 10:58:56 +1000 [thread overview]
Message-ID: <41634350.90207@yahoo.com.au> (raw)
In-Reply-To: <200410060042.i960gn631637@unix-os.sc.intel.com>
Chen, Kenneth W wrote:
> Chen, Kenneth W wrote on Tuesday, October 05, 2004 10:31 AM
>
>>We have experimented with similar thing, via bumping up sd->cache_hot_time to
>>a very large number, like 1 sec. What we measured was a equally low throughput.
>>But that was because of not enough load balancing.
>
>
> Since we are talking about load balancing, we decided to measure various
> value for cache_hot_time variable to see how it affects app performance. We
> first establish baseline number with vanilla base kernel (default at 2.5ms),
> then sweep that variable up to 1000ms. All of the experiments are done with
> Ingo's patch posted earlier. Here are the result (test environment is 4-way
> SMP machine, 32 GB memory, 500 disks running industry standard db transaction
> processing workload):
>
> cache_hot_time | workload throughput
> --------------------------------------
> 2.5ms - 100.0 (0% idle)
> 5ms - 106.0 (0% idle)
> 10ms - 112.5 (1% idle)
> 15ms - 111.6 (3% idle)
> 25ms - 111.1 (5% idle)
> 250ms - 105.6 (7% idle)
> 1000ms - 105.4 (7% idle)
>
> Clearly the default value for SMP has the worst application throughput (12%
> below peak performance). When set too low, kernel is too aggressive on load
> balancing and we are still seeing cache thrashing despite the perf fix.
> However, If set too high, kernel gets too conservative and not doing enough
> load balance.
>
Great testing, thanks.
> This value was default to 10ms before domain scheduler, why does domain
> scheduler need to change it to 2.5ms? And on what bases does that decision
> take place? We are proposing change that number back to 10ms.
>
IIRC Ingo wanted it lower, to closer match previous values (correct
me if I'm wrong).
I think your patch would be fine though (when timeslicing tasks on
the same CPU, I've typically seen large regressions when going below
a 10ms timeslice, even on a small cache CPU (512K).
next prev parent reply other threads:[~2004-10-06 0:59 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-06 0:42 Default cache_hot_time value back to 10ms Chen, Kenneth W
2004-10-06 0:47 ` Con Kolivas
2004-10-06 1:02 ` Nick Piggin
2004-10-06 0:58 ` Nick Piggin [this message]
2004-10-06 3:55 ` Andrew Morton
2004-10-06 4:30 ` Nick Piggin
2004-10-06 4:51 ` Andrew Morton
2004-10-06 5:00 ` Nick Piggin
2004-10-06 5:09 ` Andrew Morton
2004-10-06 5:21 ` Nick Piggin
2004-10-06 5:33 ` Andrew Morton
2004-10-06 5:46 ` Nick Piggin
2004-10-06 6:19 ` new dev model (was Re: Default cache_hot_time value back to 10ms) Jeff Garzik
2004-10-06 6:39 ` Andrew Morton
2004-10-06 8:56 ` Paolo Ciarrocchi
2004-10-06 9:44 ` bert hubert
2004-10-06 14:00 ` Andries Brouwer
2004-10-06 19:40 ` Jeff Garzik
2004-10-06 19:48 ` Jeff Garzik
2004-10-06 19:58 ` Jeff Garzik
2004-10-06 20:37 ` Geert Uytterhoeven
2004-10-07 1:08 ` Jeff Garzik
2004-10-07 0:02 ` Matt Mackall
2004-10-06 9:23 ` Ingo Molnar
2004-10-06 9:57 ` Paolo Ciarrocchi
2004-10-06 19:33 ` Jeff Garzik
2004-10-06 22:23 ` Martin J. Bligh
2004-10-06 5:52 ` Default cache_hot_time value back to 10ms Chen, Kenneth W
2004-10-06 19:27 ` Chen, Kenneth W
2004-10-06 19:39 ` Andrew Morton
2004-10-06 20:38 ` Chen, Kenneth W
2004-10-06 20:43 ` Andrew Morton
2004-10-06 23:14 ` Chen, Kenneth W
2004-10-07 2:26 ` Nick Piggin
2004-10-07 6:29 ` Ingo Molnar
2004-10-07 7:08 ` Jeff Garzik
2004-10-07 7:26 ` Ingo Molnar
2004-10-06 20:50 ` Ingo Molnar
2004-10-06 21:03 ` Chen, Kenneth W
2004-10-06 7:48 ` Ingo Molnar
2004-10-06 17:18 ` Chen, Kenneth W
2004-10-06 19:55 ` Ingo Molnar
2004-10-06 22:46 ` Peter Williams
2004-10-06 13:29 ` [patch] sched: auto-tuning task-migration Ingo Molnar
2004-10-06 13:44 ` Nick Piggin
2004-10-06 17:49 ` Chen, Kenneth W
2004-10-06 20:04 ` Ingo Molnar
2004-10-06 21:18 ` Chen, Kenneth W
2004-10-07 6:10 ` Ingo Molnar
2005-02-21 5:08 ` Paul Jackson
[not found] <200410071028.01931.habanero@us.ibm.com>
2004-10-07 15:58 ` Default cache_hot_time value back to 10ms Andrew Theurer
2004-10-08 9:47 ` Nick Piggin
2004-10-08 14:11 ` Andrew Theurer
-- strict thread matches above, loose matches on Subject: below --
2004-10-07 18:44 Albert Cahalan
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=41634350.90207@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=kenneth.w.chen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.