From: Ingo Molnar <mingo@elte.hu>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chuck Ebbert <cebbert@redhat.com>,
Antoine Martin <antoine@nagafix.co.uk>,
Satyam Sharma <satyam.sharma@gmail.com>,
Linux Kernel Development <linux-kernel@vger.kernel.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: CFS: some bad numbers with Java/database threading [FIXED]
Date: Wed, 19 Sep 2007 21:56:33 +0200 [thread overview]
Message-ID: <20070919195633.GA23595@elte.hu> (raw)
In-Reply-To: <alpine.LFD.0.999.0709191230230.16478@woody.linux-foundation.org>
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > Linus, what do you think? I have no strong feelings, I think the
> > patch cannot hurt (it does not change anything by default) - but we
> > should not turn the workaround flag on by default.
>
> I disagree. I think CFS made "sched_yield()" worse, and what you call
> "bug workaround" is likely the *better* behaviour.
>
> The fact is, sched_yield() is not - and should not be - about
> "recalculating the position in the scheduler queue" like you do now in
> CFS.
>
> It very much is about moving the thread *dead last* within its
> priority group.
[...]
> and quite frankly, the current CFS behaviour simply looks buggy. It
> should simply not move it to the "right place" in the rbtree. It
> should move it *last*.
ok, we can do that.
the O(1) implementation of yield() was pretty arbitrary: it did not move
it last on the same priority level - it only did it within the active
array. So expired tasks (such as CPU hogs) would come _after_ a
yield()-ing task.
so the yield() implementation was so much tied to the data structures of
the O(1) scheduler that it was impossible to fully emulate it in CFS.
in CFS we dont have a per-nice-level rbtree, so we cannot move it dead
last within the same priority group - but we can move it dead last in
the whole tree. (then they'd be put even after nice +19 tasks.) People
might complain about _that_.
another practical problem is that this will break certain desktop apps
that do calls to yield() [some firefox plugins do that, some 3D apps do
that, etc.] but they dont expect to be moved 'very late' into the queue
- they expect the O(1) scheduler's behavior of being delayed "a bit".
(That's why i added the yield-granularity tunable.)
we can make yield super-agressive, that is pretty much the only sane
(because well-defined) thing to do (besides turning yield into a NOP),
but there will be lots of regression reports about lost interactivity
during load. sched_yield() is a mortally broken API. "fix the app" would
be the answer, but still there will be lots of complaints.
Ingo
next prev parent reply other threads:[~2007-09-19 19:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-12 23:10 CFS: some bad numbers with Java/database threading Antoine Martin
2007-09-13 7:18 ` David Schwartz
2007-09-12 23:33 ` Nick Piggin
2007-09-13 19:02 ` Antoine Martin
2007-09-13 21:47 ` David Schwartz
2007-09-13 11:24 ` CFS: " Ingo Molnar
2007-09-14 8:32 ` Ingo Molnar
2007-09-14 10:06 ` Satyam Sharma
2007-09-14 15:25 ` CFS: some bad numbers with Java/database threading [FIXED] Antoine Martin
2007-09-14 15:32 ` Ingo Molnar
2007-09-18 17:00 ` Chuck Ebbert
2007-09-18 22:46 ` Ingo Molnar
2007-09-18 23:02 ` Chuck Ebbert
2007-09-19 18:45 ` David Schwartz
2007-09-19 19:48 ` Chris Friesen
2007-09-19 22:56 ` David Schwartz
2007-09-19 23:05 ` David Schwartz
2007-09-19 23:52 ` David Schwartz
2007-09-19 19:18 ` Ingo Molnar
2007-09-19 19:39 ` Linus Torvalds
2007-09-19 19:56 ` Ingo Molnar [this message]
2007-09-19 20:26 ` Ingo Molnar
2007-09-19 20:28 ` Linus Torvalds
2007-09-19 21:41 ` Ingo Molnar
2007-09-19 21:49 ` Ingo Molnar
2007-09-19 21:58 ` Peter Zijlstra
2007-09-26 1:46 ` CFS: new java yield graphs Antoine Martin
2007-09-27 8:35 ` Ingo Molnar
2007-09-19 20:00 ` CFS: some bad numbers with Java/database threading [FIXED] Chris Friesen
2007-09-14 16:01 ` CFS: some bad numbers with Java/database threading Satyam Sharma
2007-09-14 16:08 ` Satyam Sharma
2007-09-17 12:17 ` Antoine Martin
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=20070919195633.GA23595@elte.hu \
--to=mingo@elte.hu \
--cc=a.p.zijlstra@chello.nl \
--cc=antoine@nagafix.co.uk \
--cc=cebbert@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=satyam.sharma@gmail.com \
--cc=torvalds@linux-foundation.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