From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Lin Ming <ming.m.lin@intel.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
"Zhang, Yanmin" <yanmin_zhang@linux.intel.com>,
mingo <mingo@elte.hu>
Subject: Re: oltp ~10% regression with 2.6.27-rc5 on stoakley machine
Date: Thu, 04 Sep 2008 11:03:54 +0200 [thread overview]
Message-ID: <1220519034.8609.206.camel@twins> (raw)
In-Reply-To: <1220518266.9590.22.camel@minggr>
On Thu, 2008-09-04 at 16:51 +0800, Lin Ming wrote:
> Comparing with 2.6.27-rc4, oltp has ~10% regression with 2.6.27-rc5 on
> 8-core stoakley machine.
>
> Run oltp with 8 threads 120 seconds, vmstat shows much more idle time, about ~30%
>
> procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
> r b swpd free buff cache si so bi bo in cs us sy id wa st
> 10 0 0 7822824 42240 123740 0 0 312 47 442 1613 3 2 88 6 0
> 9 0 0 7822312 42240 123764 0 0 0 16 26691 232566 56 14 30 0 0
> 13 0 0 7821940 42240 123764 0 0 0 16 26661 228689 54 14 32 0 0
> 8 0 0 7821320 42240 123764 0 0 0 16 31508 263765 61 17 23 0 0
> 12 0 0 7820948 42240 123764 0 0 16 16 28666 242402 57 15 28 0 0
> 9 0 0 7820584 42240 123780 0 0 0 16 27107 230804 56 14 30 0 0
> 10 0 0 7819964 42240 123796 0 0 16 612 27599 244037 55 16 29 0 0
> 11 0 0 7819356 42240 123796 0 0 0 64 23540 209713 51 13 36 0 0
> 10 0 0 7819212 42240 123796 0 0 0 32 25674 224205 54 13 32 0 0
> 10 0 0 7818716 42240 123796 0 0 0 20 30106 257161 59 16 25 0 0
> 7 0 0 7818468 42240 123796 0 0 0 16 28356 241551 57 14 29 0 0
> 10 0 0 7818096 42240 123796 0 0 0 16 39174 273656 64 16 20 0 0
> 12 0 0 7817724 42240 123796 0 0 0 20 39688 276936 63 16 20 0 0
> 11 0 0 7817352 42240 123796 0 0 0 16 42543 285192 66 16 18 0 0
> 9 0 0 7817352 42240 123796 0 0 0 16 37083 259830 62 14 24 0 0
> 8 0 0 7817104 42240 123796 0 0 0 16 37450 259160 61 15 23 0 0
> 10 0 0 7816516 42240 123796 0 0 0 64 37425 261870 61 16 23 0 0
> 11 0 0 7815896 42240 123812 0 0 16 16 41558 279320 66 16 18 0 0
> 9 0 0 7815648 42240 123812 0 0 0 16 34017 235741 59 14 28 0 0
> 10 0 0 7815152 42240 123812 0 0 0 16 35642 248888 60 14 26 0 0
> 9 0 0 7814532 42240 123812 0 0 0 16 38517 263220 63 15 22 0 0
> 9 0 0 7814160 42240 123812 0 0 0 20 35965 246487 61 14 25 0 0
> 10 0 0 7814036 42240 123812 0 0 0 16 33852 236313 59 13 28 0 0
> 11 0 0 7813664 42240 123812 0 0 0 16 34958 244819 59 14 27 0 0
> 10 0 0 7813416 42240 123812 0 0 0 16 26106 202062 53 10 37 0 0
> 10 0 0 7812672 42240 123812 0 0 0 16 31174 222714 56 12 32 0 0
> 9 0 0 7812300 42240 123812 0 0 0 276 25089 196813 52 11 38 0 0
> 9 0 0 7812060 42240 123812 0 0 0 16 31877 228004 57 12 31 0 0
>
>
>
> Bisect located below patch,
> after reverted this patch the regression disappear.
>
> commit 354879bb977e06695993435745f06a0f6d39ce2b
> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Mon Aug 25 17:15:34 2008 +0200
>
> sched_clock: fix cpu_clock()
>
> This patch fixes 3 issues:
>
> a) it removes the dependency on jiffies, because jiffies are
> incremented
> by a single CPU, and the tick is not synchronized between CPUs.
> Therefore
> relying on it to calculate a window to clip whacky TSC values
> doesn't work
> as it can drift around.
>
> So instead use [GTOD, GTOD+TICK_NSEC) as the window.
>
> b) __update_sched_clock() did (roughly speaking):
>
> delta = sched_clock() - scd->tick_raw;
> clock += delta;
>
> Which gives exponential growth, instead of linear.
>
> c) allows the sched_clock_cpu() value to warp the u64 without
> breaking.
>
> the results are more reliable sched_clock() deltas:
Thats bizarre... that just indicates the better clock, which should give
better (read fairer) scheduling hurts your workload.
Is there anything I can run to see if we can fix the scheduler perhaps?
next prev parent reply other threads:[~2008-09-04 10:12 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-04 8:51 oltp ~10% regression with 2.6.27-rc5 on stoakley machine Lin Ming
2008-09-04 9:03 ` Peter Zijlstra [this message]
2008-09-04 10:52 ` Lin Ming
2008-09-04 11:06 ` Peter Zijlstra
2008-09-04 12:12 ` Lin Ming
2008-09-04 12:26 ` Peter Zijlstra
2008-09-04 12:42 ` Lin Ming
2008-09-04 13:50 ` Gregory Haskins
2008-09-04 13:50 ` [PATCH 1/4] revert "sched: sched_cacheflush is now unused" Gregory Haskins
2008-09-04 13:50 ` [PATCH 2/4] Revert "[PATCH] sched: remove cache_hot_time" Gregory Haskins
2008-09-04 13:50 ` [PATCH 3/4] Revert "sched: zap the migration init / cache-hot balancing code" Gregory Haskins
2008-09-04 13:50 ` [PATCH 4/4] sched: make task_hot() once again use sd->cache_hot_time Gregory Haskins
2008-09-04 11:09 ` oltp ~10% regression with 2.6.27-rc5 on stoakley machine Ingo Molnar
2008-09-04 11:30 ` Lin Ming
2008-09-04 11:35 ` Ingo Molnar
2008-09-04 12:19 ` Lin Ming
2008-09-05 1:26 ` Lin Ming
2008-09-20 21:38 ` Peter Zijlstra
2008-09-26 2:00 ` Lin Ming
-- strict thread matches above, loose matches on Subject: below --
2008-09-04 7:06 Lin Ming
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=1220519034.8609.206.camel@twins \
--to=a.p.zijlstra@chello.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
--cc=yanmin_zhang@linux.intel.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.