From: Al Boldi <a1426z@gawab.com>
To: linux-kernel@vger.kernel.org
Subject: Re: CFS review
Date: Sat, 11 Aug 2007 13:44:42 +0300 [thread overview]
Message-ID: <200708111344.42934.a1426z@gawab.com> (raw)
Roman Zippel wrote:
> On Fri, 10 Aug 2007, Ingo Molnar wrote:
> > achieve that. It probably wont make a real difference, but it's really
> > easy for you to send and it's still very useful when one tries to
> > eliminate possibilities and when one wants to concentrate on the
> > remaining possibilities alone.
>
> The thing I'm afraid about CFS is its possible unpredictability, which
> would make it hard to reproduce problems and we may end up with users with
> unexplainable weird problems. That's the main reason I'm trying so hard to
> push for a design discussion.
>
> Just to give an idea here are two more examples of irregular behaviour,
> which are hopefully easier to reproduce.
>
> 1. Two simple busy loops, one of them is reniced to 15, according to my
> calculations the reniced task should get about 3.4% (1/(1.25^15+1)), but I
> get this:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 4433 roman 20 0 1532 300 244 R 99.2 0.2 5:05.51 l
> 4434 roman 35 15 1532 72 16 R 0.7 0.1 0:10.62 l
>
> OTOH upto nice level 12 I get what I expect.
>
> 2. If I start 20 busy loops, initially I see in top that every task gets
> 5% and time increments equally (as it should):
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 4492 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4491 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4490 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4489 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4488 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4487 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4486 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4485 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4484 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4483 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4482 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4481 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4480 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4479 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4478 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4477 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4476 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4475 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4474 roman 20 0 1532 68 16 R 5.0 0.1 0:02.86 l
> 4473 roman 20 0 1532 296 244 R 5.0 0.2 0:02.86 l
>
> But if I renice all of them to -15, the time every task gets is rather
> random:
>
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 4492 roman 5 -15 1532 68 16 R 1.0 0.1 0:07.95 l
> 4491 roman 5 -15 1532 68 16 R 4.3 0.1 0:07.62 l
> 4490 roman 5 -15 1532 68 16 R 3.3 0.1 0:07.50 l
> 4489 roman 5 -15 1532 68 16 R 7.6 0.1 0:07.80 l
> 4488 roman 5 -15 1532 68 16 R 9.6 0.1 0:08.31 l
> 4487 roman 5 -15 1532 68 16 R 3.3 0.1 0:07.59 l
> 4486 roman 5 -15 1532 68 16 R 6.6 0.1 0:07.08 l
> 4485 roman 5 -15 1532 68 16 R 10.0 0.1 0:07.31 l
> 4484 roman 5 -15 1532 68 16 R 8.0 0.1 0:07.30 l
> 4483 roman 5 -15 1532 68 16 R 7.0 0.1 0:07.34 l
> 4482 roman 5 -15 1532 68 16 R 1.0 0.1 0:05.84 l
> 4481 roman 5 -15 1532 68 16 R 1.0 0.1 0:07.16 l
> 4480 roman 5 -15 1532 68 16 R 3.3 0.1 0:07.00 l
> 4479 roman 5 -15 1532 68 16 R 1.0 0.1 0:06.66 l
> 4478 roman 5 -15 1532 68 16 R 8.6 0.1 0:06.96 l
> 4477 roman 5 -15 1532 68 16 R 8.6 0.1 0:07.63 l
> 4476 roman 5 -15 1532 68 16 R 9.6 0.1 0:07.38 l
> 4475 roman 5 -15 1532 68 16 R 1.3 0.1 0:07.09 l
> 4474 roman 5 -15 1532 68 16 R 2.3 0.1 0:07.97 l
> 4473 roman 5 -15 1532 296 244 R 1.0 0.2 0:07.73 l
That's because granularity increases when decreasing nice, and results in
larger timeslices, which affects smoothness negatively. chew.c easily shows
this problem with 2 background cpu-hogs at the same nice-level.
pid 908, prio 0, out for 8 ms, ran for 4 ms, load 37%
pid 908, prio 0, out for 8 ms, ran for 4 ms, load 37%
pid 908, prio 0, out for 8 ms, ran for 2 ms, load 26%
pid 908, prio 0, out for 8 ms, ran for 4 ms, load 38%
pid 908, prio 0, out for 2 ms, ran for 1 ms, load 47%
pid 908, prio -5, out for 23 ms, ran for 3 ms, load 14%
pid 908, prio -5, out for 17 ms, ran for 9 ms, load 35%
pid 908, prio -5, out for 18 ms, ran for 6 ms, load 27%
pid 908, prio -5, out for 20 ms, ran for 10 ms, load 34%
pid 908, prio -5, out for 9 ms, ran for 3 ms, load 30%
pid 908, prio -10, out for 69 ms, ran for 8 ms, load 11%
pid 908, prio -10, out for 35 ms, ran for 19 ms, load 36%
pid 908, prio -10, out for 58 ms, ran for 20 ms, load 26%
pid 908, prio -10, out for 34 ms, ran for 17 ms, load 34%
pid 908, prio -10, out for 58 ms, ran for 23 ms, load 28%
pid 908, prio -15, out for 164 ms, ran for 20 ms, load 11%
pid 908, prio -15, out for 21 ms, ran for 11 ms, load 36%
pid 908, prio -15, out for 21 ms, ran for 12 ms, load 37%
pid 908, prio -15, out for 115 ms, ran for 14 ms, load 11%
pid 908, prio -15, out for 27 ms, ran for 22 ms, load 45%
pid 908, prio -15, out for 125 ms, ran for 33 ms, load 21%
pid 908, prio -15, out for 54 ms, ran for 16 ms, load 22%
pid 908, prio -15, out for 34 ms, ran for 33 ms, load 49%
pid 908, prio -15, out for 94 ms, ran for 15 ms, load 14%
pid 908, prio -15, out for 29 ms, ran for 21 ms, load 42%
pid 908, prio -15, out for 108 ms, ran for 20 ms, load 15%
pid 908, prio -15, out for 44 ms, ran for 20 ms, load 31%
pid 908, prio -15, out for 34 ms, ran for 110 ms, load 76%
pid 908, prio -15, out for 132 ms, ran for 21 ms, load 14%
pid 908, prio -15, out for 42 ms, ran for 39 ms, load 48%
pid 908, prio -15, out for 57 ms, ran for 124 ms, load 68%
pid 908, prio -15, out for 44 ms, ran for 17 ms, load 28%
It looks like the larger the granularity, the more unpredictable it gets,
which probably means that this unpredictability exists even at smaller
granularity but is only exposed with larger ones.
Thanks!
--
Al
next reply other threads:[~2007-08-11 10:44 UTC|newest]
Thread overview: 123+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-11 10:44 Al Boldi [this message]
2007-08-12 4:17 ` Ingo Molnar
2007-08-12 15:27 ` Al Boldi
2007-08-12 15:52 ` Ingo Molnar
2007-08-12 19:43 ` Al Boldi
2007-08-21 10:58 ` Ingo Molnar
2007-08-21 22:27 ` Al Boldi
2007-08-24 13:45 ` Ingo Molnar
2007-08-25 22:27 ` Al Boldi
2007-08-25 23:15 ` Ingo Molnar
2007-08-26 16:27 ` Al Boldi
2007-08-26 16:39 ` Ingo Molnar
2007-08-27 4:06 ` Al Boldi
2007-08-27 10:53 ` Ingo Molnar
2007-08-27 14:46 ` Al Boldi
2007-08-27 20:41 ` Ingo Molnar
2007-08-28 4:37 ` Al Boldi
2007-08-28 5:05 ` Linus Torvalds
2007-08-28 5:23 ` Al Boldi
2007-08-28 7:28 ` Mike Galbraith
2007-08-28 7:36 ` Ingo Molnar
2007-08-28 16:34 ` Linus Torvalds
2007-08-28 16:44 ` Arjan van de Ven
2007-08-28 16:45 ` Ingo Molnar
2007-08-29 4:19 ` Al Boldi
2007-08-29 4:53 ` Ingo Molnar
2007-08-29 5:58 ` Al Boldi
2007-08-29 6:43 ` Ingo Molnar
2007-08-28 20:46 ` Valdis.Kletnieks
2007-08-28 7:43 ` Xavier Bestel
2007-08-28 8:02 ` Ingo Molnar
2007-08-28 19:19 ` Willy Tarreau
2007-08-28 19:55 ` Ingo Molnar
2007-08-29 4:18 ` Ingo Molnar
2007-08-29 4:29 ` Keith Packard
2007-08-29 4:46 ` Ingo Molnar
2007-08-29 7:57 ` Keith Packard
2007-08-29 8:04 ` Ingo Molnar
2007-08-29 8:53 ` Al Boldi
2007-08-29 15:57 ` Keith Packard
2007-08-29 19:56 ` Rene Herman
2007-08-30 7:05 ` Rene Herman
2007-08-30 7:20 ` Ingo Molnar
2007-08-31 6:46 ` Tilman Sauerbeck
2007-08-31 10:44 ` DRM and/or X trouble (was Re: CFS review) Rene Herman
2007-08-31 14:55 ` DRM and/or X trouble Satyam Sharma
2007-08-30 16:06 ` CFS review Chuck Ebbert
2007-08-30 16:48 ` Rene Herman
2007-08-29 4:40 ` Mike Galbraith
2007-08-29 3:42 ` Bill Davidsen
2007-08-29 3:37 ` Bill Davidsen
2007-08-29 3:45 ` Ingo Molnar
2007-08-29 13:11 ` Bill Davidsen
-- strict thread matches above, loose matches on Subject: below --
2007-07-10 8:31 -mm merge plans for 2.6.23 Andrew Morton
2007-07-11 12:43 ` x86 status was " Andi Kleen
2007-07-11 17:42 ` Ingo Molnar
2007-07-11 21:16 ` Andi Kleen
2007-07-11 21:46 ` Andrea Arcangeli
2007-07-11 22:09 ` Linus Torvalds
2007-07-13 2:23 ` Roman Zippel
2007-07-13 4:47 ` Mike Galbraith
2007-07-13 17:23 ` Roman Zippel
2007-07-14 5:04 ` Mike Galbraith
2007-08-01 3:41 ` CFS review Roman Zippel
2007-08-01 7:12 ` Ingo Molnar
2007-08-01 7:26 ` Mike Galbraith
2007-08-01 7:30 ` Ingo Molnar
2007-08-01 7:36 ` Mike Galbraith
2007-08-01 8:49 ` Mike Galbraith
2007-08-01 13:19 ` Roman Zippel
2007-08-01 15:07 ` Ingo Molnar
2007-08-01 17:10 ` Andi Kleen
2007-08-01 16:27 ` Linus Torvalds
2007-08-01 17:48 ` Andi Kleen
2007-08-01 17:50 ` Ingo Molnar
2007-08-01 18:01 ` Roman Zippel
2007-08-01 19:05 ` Ingo Molnar
2007-08-09 23:14 ` Roman Zippel
2007-08-10 5:49 ` Ingo Molnar
2007-08-10 13:52 ` Roman Zippel
2007-08-10 14:18 ` Ingo Molnar
2007-08-10 16:47 ` Mike Galbraith
2007-08-10 17:19 ` Roman Zippel
2007-08-10 16:54 ` Michael Chang
2007-08-10 17:25 ` Roman Zippel
2007-08-10 19:44 ` Ingo Molnar
2007-08-10 19:47 ` Willy Tarreau
2007-08-10 21:15 ` Roman Zippel
2007-08-10 21:36 ` Ingo Molnar
2007-08-10 22:50 ` Roman Zippel
2007-08-11 5:28 ` Willy Tarreau
2007-08-12 5:17 ` Ingo Molnar
2007-08-11 0:30 ` Ingo Molnar
2007-08-20 22:19 ` Roman Zippel
2007-08-21 7:33 ` Mike Galbraith
2007-08-21 8:35 ` Ingo Molnar
2007-08-21 11:54 ` Roman Zippel
2007-08-11 5:15 ` Willy Tarreau
2007-08-10 7:23 ` Mike Galbraith
2007-08-01 11:22 ` Ingo Molnar
2007-08-01 12:21 ` Roman Zippel
2007-08-01 12:23 ` Ingo Molnar
2007-08-01 13:59 ` Ingo Molnar
2007-08-01 14:04 ` Arjan van de Ven
2007-08-01 15:44 ` Roman Zippel
2007-08-01 17:41 ` Ingo Molnar
2007-08-01 18:14 ` Roman Zippel
2007-08-03 3:04 ` Matt Mackall
2007-08-03 3:57 ` Arjan van de Ven
2007-08-03 4:18 ` Willy Tarreau
2007-08-03 4:31 ` Arjan van de Ven
2007-08-03 4:53 ` Willy Tarreau
2007-08-03 4:38 ` Matt Mackall
2007-08-03 8:44 ` Ingo Molnar
2007-08-03 9:29 ` Andi Kleen
2007-08-01 11:37 ` Ingo Molnar
2007-08-01 12:27 ` Roman Zippel
2007-08-01 13:20 ` Andi Kleen
2007-08-01 13:33 ` Roman Zippel
2007-08-01 14:36 ` Ingo Molnar
2007-08-01 16:11 ` Andi Kleen
2007-08-02 2:17 ` Linus Torvalds
2007-08-02 4:57 ` Willy Tarreau
2007-08-02 10:43 ` Andi Kleen
2007-08-02 10:07 ` Willy Tarreau
2007-08-02 16:09 ` Ingo Molnar
2007-08-02 22:38 ` Roman Zippel
2007-08-02 19:16 ` Daniel Phillips
2007-08-02 23:23 ` Roman Zippel
2007-08-01 14:40 ` Ingo Molnar
2007-08-01 14:49 ` Peter Zijlstra
2007-08-02 17:36 ` Roman Zippel
2007-08-02 15:46 ` Ingo Molnar
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=200708111344.42934.a1426z@gawab.com \
--to=a1426z@gawab.com \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®