From: Greg Smith <gsmith@gregsmith.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Mike Galbraith <efault@gmx.de>,
Dhaval Giani <dhaval@linux.vnet.ibm.com>,
lkml <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Subject: Re: PostgreSQL pgbench performance regression in 2.6.23+
Date: Fri, 23 May 2008 03:13:32 -0400 (EDT) [thread overview]
Message-ID: <Pine.GSO.4.64.0805230232190.28654@westnet.com> (raw)
In-Reply-To: <1211459081.29104.40.camel@twins>
On Thu, 22 May 2008, Peter Zijlstra wrote:
> I picked the wake_affine() condition, because I think that is the
> biggest factor in this behaviour.
I tested out Peter's patch (updated version against -rc3 with a typo fix
from Mike below) and it's a big step in the right direction. Here are
updated results from my benchmark script, adding 2.6.26-rc3 and that rev
with this patch applied:
Clients 2.6.22 2.6.24 2.6.25 -rc3 patch
1 11052 10526 10700 10193 10439
2 16352 14447 10370 9817 13289
3 15414 17784 9403 9428 13678
4 14290 16832 8882 9533 13033
5 14211 16356 8527 9558 12790
6 13291 16763 9473 9367 12660
8 12374 15343 9093 9159 12357
10 11218 10732 9057 8711 11839
15 11116 7460 7113 7620 11267
20 11412 7171 7017 7707 10531
30 11191 7049 6896 7195 9766
40 11062 7001 6820 7079 9668
50 11255 6915 6797 7202 9588
Exact versions I tested because I think it may start mattering now:
2.6.22.19, 2.6.24.3, 2.6.25. I didn't save 2.6.23 results but recall them
being similar to 2.6.24.
On this dual-core system, without this patch there's an average of a a 33%
regression in -rc3 compared to 2.6.22. With it that's dropped to 8%; some
cases (around 10 clients) even improve a touch (it's enough within the
margin of error here I wouldn't conclude too much from that). The big
jump in high client count cases is the first I've seen that since CFS was
introduced. It seems a bit odd to me that there's still such a large
regression in the 2-8 client cases compared with not only 2.6.22 but
2.6.24, which owned this benchmark in that area.
With this feedback, any ideas on where to go next? There seems like's
some room for improvement still left here.
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 5395a61..e160f71 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -965,6 +965,8 @@ struct sched_entity {
u64 last_wakeup;
u64 avg_overlap;
+ struct sched_entity *waker;
+
#ifdef CONFIG_SCHEDSTATS
u64 wait_start;
u64 wait_max;
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index e24ecd3..9db3cb4 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -1066,7 +1066,8 @@ wake_affine(struct rq *rq, struct sched_domain
*this_sd, struct rq *this_rq,
* a reasonable amount of time then attract this newly
* woken task:
*/
- if (sync && curr->sched_class == &fair_sched_class) {
+ if (sync && curr->sched_class == &fair_sched_class &&
+ p->se.waker == curr->se.waker) {
if (curr->se.avg_overlap < sysctl_sched_migration_cost &&
p->se.avg_overlap <
sysctl_sched_migration_cost)
return 1;
@@ -1238,6 +1239,7 @@ static void check_preempt_wakeup(struct rq *rq,
struct task_struct *p)
if (unlikely(se == pse))
return;
+ se->waker = pse;
cfs_rq_of(pse)->next = pse;
/*
--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD
next prev parent reply other threads:[~2008-05-23 7:17 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-21 17:34 PostgreSQL pgbench performance regression in 2.6.23+ Greg Smith
2008-05-22 7:10 ` Mike Galbraith
2008-05-22 8:28 ` Dhaval Giani
2008-05-22 9:05 ` Mike Galbraith
2008-05-22 10:34 ` Mike Galbraith
2008-05-22 11:25 ` Mike Galbraith
2008-05-22 11:44 ` Peter Zijlstra
2008-05-22 12:09 ` Mike Galbraith
2008-05-22 12:24 ` Peter Zijlstra
2008-05-22 13:16 ` Mike Galbraith
2008-05-23 7:13 ` Greg Smith [this message]
2008-05-23 10:00 ` Mike Galbraith
2008-05-23 10:10 ` Ingo Molnar
2008-05-23 10:15 ` Mike Galbraith
2008-05-23 23:18 ` Greg Smith
2008-05-23 23:46 ` Mike Galbraith
2008-05-24 8:08 ` Mike Galbraith
2008-05-27 0:28 ` Greg Smith
2008-05-27 5:59 ` [patch] " Mike Galbraith
2008-05-27 8:20 ` Mike Galbraith
2008-05-27 8:35 ` Mike Galbraith
2008-06-06 5:03 ` Greg Smith
2008-06-06 6:13 ` Mike Galbraith
2008-06-07 11:38 ` Mike Galbraith
2008-06-07 12:50 ` Mike Galbraith
2008-06-07 13:07 ` Peter Zijlstra
2008-06-07 14:16 ` Mike Galbraith
2008-06-07 16:16 ` Peter Zijlstra
2008-06-07 17:56 ` Mike Galbraith
2008-06-07 13:08 ` Peter Zijlstra
2008-06-07 14:54 ` [patch part 2] " Mike Galbraith
2008-06-07 16:12 ` Peter Zijlstra
2008-06-07 17:53 ` Mike Galbraith
2008-06-07 18:19 ` Mike Galbraith
2008-05-23 13:05 ` Mike Galbraith
2008-05-23 13:35 ` Mike Galbraith
-- strict thread matches above, loose matches on Subject: below --
2008-05-23 11:26 Anton Petrusevich
2008-05-23 18:46 ` Greg Smith
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=Pine.GSO.4.64.0805230232190.28654@westnet.com \
--to=gsmith@gregsmith.com \
--cc=dhaval@linux.vnet.ibm.com \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=vatsa@linux.vnet.ibm.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