From: Chris Snook <csnook@redhat.com>
To: tim.c.chen@linux.intel.com
Cc: Andrea Arcangeli <andrea@suse.de>,
mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: pluggable scheduler thread (was Re: Volanomark slows by 80% under CFS)
Date: Mon, 30 Jul 2007 17:07:46 -0400 [thread overview]
Message-ID: <46AE5322.9030605@redhat.com> (raw)
In-Reply-To: <1185821379.19777.58.camel@localhost.localdomain>
Tim Chen wrote:
> On Sat, 2007-07-28 at 02:51 -0400, Chris Snook wrote:
>
>> Tim --
>>
>> Since you're already set up to do this benchmarking, would you mind
>> varying the parameters a bit and collecting vmstat data? If you want to
>> run oprofile too, that wouldn't hurt.
>>
>
> Here's the vmstat data. The number of runnable processes are
> fewer and there're more contex switches with CFS.
>
> The vmstat for 2.6.22 looks like
>
> procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
> r b swpd free buff cache si so bi bo in cs us sy id wa st
> 391 0 0 1722564 14416 95472 0 0 169 25 76 6520 3 3 89 5 0
> 400 0 0 1722372 14416 95496 0 0 0 0 264 641685 47 53 0 0 0
> 368 0 0 1721504 14424 95496 0 0 0 7 261 648493 46 51 3 0 0
> 438 0 0 1721504 14432 95496 0 0 0 2 264 690834 46 54 0 0 0
> 400 0 0 1721380 14432 95496 0 0 0 0 260 657157 46 53 1 0 0
> 393 0 0 1719892 14440 95496 0 0 0 6 265 671599 45 53 2 0 0
> 423 0 0 1719892 14440 95496 0 0 0 15 264 701626 44 56 0 0 0
> 375 0 0 1720240 14472 95504 0 0 0 72 265 671795 43 53 3 0 0
> 393 0 0 1720140 14480 95504 0 0 0 7 265 733561 45 55 0 0 0
> 355 0 0 1716052 14480 95504 0 0 0 0 260 670676 43 54 3 0 0
> 419 0 0 1718900 14480 95504 0 0 0 4 265 680690 43 55 2 0 0
> 396 0 0 1719148 14488 95504 0 0 0 3 261 712307 43 56 0 0 0
> 395 0 0 1719148 14488 95504 0 0 0 2 264 692781 44 54 1 0 0
> 387 0 0 1719148 14492 95504 0 0 0 41 268 709579 43 57 0 0 0
> 420 0 0 1719148 14500 95504 0 0 0 3 265 690862 44 54 2 0 0
> 429 0 0 1719396 14500 95504 0 0 0 0 260 704872 46 54 0 0 0
> 460 0 0 1719396 14500 95504 0 0 0 0 264 716272 46 54 0 0 0
> 419 0 0 1719396 14508 95504 0 0 0 3 261 685864 43 55 2 0 0
> 455 0 0 1719396 14508 95504 0 0 0 0 264 703718 44 56 0 0 0
> 395 0 0 1719372 14540 95512 0 0 0 64 265 692785 45 54 1 0 0
> 424 0 0 1719396 14548 95512 0 0 0 10 265 732866 45 55 0 0 0
>
> While 2.6.23-rc1 look like
> procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
> r b swpd free buff cache si so bi bo in cs us sy id wa st
> 23 0 0 1705992 17020 95720 0 0 0 0 261 1010016 53 42 5 0 0
> 7 0 0 1706116 17020 95720 0 0 0 13 267 1060997 52 41 7 0 0
> 5 0 0 1706116 17020 95720 0 0 0 28 266 1313361 56 41 3 0 0
> 19 0 0 1706116 17028 95720 0 0 0 8 265 1273669 55 41 4 0 0
> 18 0 0 1706116 17032 95720 0 0 0 2 262 1403588 55 41 4 0 0
> 23 0 0 1706116 17032 95720 0 0 0 0 264 1272561 56 40 4 0 0
> 14 0 0 1706116 17032 95720 0 0 0 0 262 1046795 55 40 5 0 0
> 16 0 0 1706116 17032 95720 0 0 0 0 260 1361102 58 39 4 0 0
> 4 0 0 1706224 17120 95724 0 0 0 126 273 1488711 56 41 3 0 0
> 24 0 0 1706224 17128 95724 0 0 0 6 261 1408432 55 41 4 0 0
> 3 0 0 1706240 17128 95724 0 0 0 48 273 1299203 54 42 4 0 0
> 16 0 0 1706240 17132 95724 0 0 0 3 261 1356609 54 42 4 0 0
> 5 0 0 1706364 17132 95724 0 0 0 0 264 1293198 58 39 3 0 0
> 9 0 0 1706364 17132 95724 0 0 0 0 261 1555153 56 41 3 0 0
> 13 0 0 1706364 17132 95724 0 0 0 0 264 1160296 56 40 4 0 0
> 8 0 0 1706364 17132 95724 0 0 0 0 261 1388909 58 38 4 0 0
> 18 0 0 1706364 17132 95724 0 0 0 0 264 1236774 56 39 5 0 0
> 11 0 0 1706364 17136 95724 0 0 0 2 261 1360325 57 40 3 0 0
> 5 0 0 1706364 17136 95724 0 0 0 1 265 1201912 57 40 3 0 0
> 8 0 0 1706364 17136 95724 0 0 0 0 261 1104308 57 39 4 0 0
> 7 0 0 1705976 17232 95724 0 0 0 127 274 1205212 58 39 4 0 0
>
> Tim
>
From a scheduler performance perspective, it looks like CFS is doing much
better on this workload. It's spending a lot less time in %sys despite the
higher context switches, and there are far fewer tasks waiting for CPU time.
The real problem seems to be that volanomark is optimized for a particular
scheduler behavior.
That's not to say that we can't improve volanomark performance under CFS, but
simply that CFS isn't so fundamentally flawed that this is impossible.
When I initially agreed with zeroing out wait time in sched_yield, I didn't
realize that it could be negative and that this would actually promote processes
in some cases. I still think it's reasonable to zero out positive wait times.
Can you test to see if that optimization does better than unconditionally
zeroing them out?
-- Chris
next prev parent reply other threads:[~2007-07-30 21:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-27 22:01 Volanomark slows by 80% under CFS Tim Chen
2007-07-28 0:31 ` Chris Snook
2007-07-28 0:59 ` Andrea Arcangeli
2007-07-28 3:43 ` pluggable scheduler flamewar thread (was Re: Volanomark slows by 80% under CFS) Chris Snook
2007-07-28 5:01 ` pluggable scheduler " Andrea Arcangeli
2007-07-28 6:51 ` Chris Snook
2007-07-30 18:49 ` Tim Chen
2007-07-30 21:07 ` Chris Snook [this message]
2007-07-30 21:24 ` Andrea Arcangeli
2007-07-28 13:28 ` Volanomark slows by 80% under CFS Dmitry Adamushko
2007-07-28 2:47 ` Rik van Riel
2007-07-28 20:26 ` Dave Jones
2007-07-28 12:36 ` Dmitry Adamushko
2007-07-28 18:55 ` David Schwartz
2007-07-29 17:37 ` [patch] sched: yield debugging Ingo Molnar
2007-07-30 18:10 ` Tim Chen
2007-07-31 20:33 ` Ingo Molnar
2007-08-01 20:53 ` Tim Chen
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=46AE5322.9030605@redhat.com \
--to=csnook@redhat.com \
--cc=andrea@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tim.c.chen@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.