| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1220511982.9590.17.camel@minggr>
Date: Thu, 04 Sep 2008 15:06:22 +0800
From: Lin Ming <ming.m.lin@...el.com>
To: a.p.zijlstra@...llo.n
Cc: linux-kernel <linux-kernel@...r.kernel.org>, mingo@...e.hu,
"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
Subject: oltp ~10% regression with 2.6.27-rc5 on stoakley machine
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, as below
sysbench --test=oltp --mysql-user=root --mysql-db=mysql --max-time=120
--max-requests=0 --oltp-read-only=on --num-threads=8 run
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@...llo.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:
-Lin Ming
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists