From: Ingo Molnar <mingo@elte.hu>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>,
Arjan van de Ven <arjan@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: sched_yield: delete sysctl_sched_compat_yield
Date: Mon, 3 Dec 2007 10:57:19 +0100 [thread overview]
Message-ID: <20071203095719.GA23106@elte.hu> (raw)
In-Reply-To: <200712032017.19661.nickpiggin@yahoo.com.au>
* Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> > as far as desktop apps such as firefox goes, the exact opposite is
> > true. We had two choices basically: either a "more agressive" yield
> > than before or a "less agressive" yield. Desktop apps were reported
> > to hurt from a "more agressive" yield (firefox for example gets some
> > pretty bad delays), so we defaulted to the less agressive method.
> > (and we defaulted to that in v2.6.23 already)
>
> Yeah, I doubt the 2.6.23 scheduler will be usable for distros
> though...
... which is a pretty gross exaggeration belied by distros already
running v2.6.23. Sure, "enterprise" distros might not run .23 (or .22 or
.21 or .24) because those are slow to adopt and pick _one_ upstream
kernel every 10 releases without bothering much about anything
inbetween. So the enterprise distros might in fact want to see 1-2
iterations of the scheduler before they switch to it. (But by that
argument 80% of the other upstream kernels were not used by enterprise
distros either, so this is nothing new.)
> I was just talking about the default because I didn't know the reason
> for the way it was set -- now that I do, we should talk about trying
> to improve the actual code so we don't need 2 defaults.
I've got the patch below queued up: it uses the more agressive yield
implementation for SCHED_BATCH tasks. SCHED_BATCH is a natural
differentiator, it's a "I dont care about latency, it's all about
throughput for me" signal from the application.
But first and foremost, do you realize that there will be no easy
solutions to this topic, that it's not just about 'flipping a default'?
Ingo
-------------->
Subject: sched: default to more agressive yield for SCHED_BATCH tasks
From: Ingo Molnar <mingo@elte.hu>
do more agressive yield for SCHED_BATCH tasks.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
kernel/sched_fair.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
Index: linux/kernel/sched_fair.c
===================================================================
--- linux.orig/kernel/sched_fair.c
+++ linux/kernel/sched_fair.c
@@ -824,8 +824,9 @@ static void dequeue_task_fair(struct rq
*/
static void yield_task_fair(struct rq *rq)
{
- struct cfs_rq *cfs_rq = task_cfs_rq(rq->curr);
- struct sched_entity *rightmost, *se = &rq->curr->se;
+ struct task_struct *curr = rq->curr;
+ struct cfs_rq *cfs_rq = task_cfs_rq(curr);
+ struct sched_entity *rightmost, *se = &curr->se;
/*
* Are we the only task in the tree?
@@ -833,7 +834,7 @@ static void yield_task_fair(struct rq *r
if (unlikely(cfs_rq->nr_running == 1))
return;
- if (likely(!sysctl_sched_compat_yield)) {
+ if (likely(!sysctl_sched_compat_yield) && curr->policy != SCHED_BATCH) {
__update_rq_clock(rq);
/*
* Update run-time statistics of the 'current'.
next prev parent reply other threads:[~2007-12-03 9:57 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-27 9:33 sched_yield: delete sysctl_sched_compat_yield Zhang, Yanmin
2007-11-27 11:17 ` Ingo Molnar
2007-11-27 22:57 ` Arjan van de Ven
2007-11-30 2:46 ` Nick Piggin
2007-11-30 2:51 ` Arjan van de Ven
2007-11-30 3:02 ` Nick Piggin
2007-11-30 3:15 ` Zhang, Yanmin
2007-11-30 3:29 ` Nick Piggin
2007-11-30 4:32 ` Zhang, Yanmin
2007-11-30 10:08 ` Ingo Molnar
2007-12-03 4:27 ` Nick Piggin
2007-12-03 8:45 ` Ingo Molnar
2007-12-03 9:17 ` Nick Piggin
2007-12-03 9:35 ` Zhang, Yanmin
2007-12-03 9:57 ` Ingo Molnar [this message]
2007-12-03 10:15 ` Nick Piggin
2007-12-03 10:33 ` Ingo Molnar
2007-12-03 11:02 ` Nick Piggin
2007-12-03 11:37 ` Ingo Molnar
2007-12-03 17:04 ` David Schwartz
2007-12-03 17:37 ` Chris Friesen
2007-12-03 19:12 ` David Schwartz
2007-12-03 19:56 ` Chris Friesen
2007-12-03 21:39 ` Mark Lord
2007-12-03 21:48 ` Ingo Molnar
2007-12-03 21:57 ` Mark Lord
2007-12-03 22:05 ` Ingo Molnar
2007-12-03 22:18 ` Mark Lord
2007-12-03 22:33 ` Ingo Molnar
2007-12-04 0:18 ` Nick Piggin
2007-12-04 0:30 ` David Schwartz
2007-12-04 2:09 ` Nick Piggin
2007-12-04 1:02 ` Nick Piggin
2007-12-03 9:41 ` Zhang, Yanmin
2007-12-03 10:17 ` Ingo Molnar
2007-12-03 9:29 ` Zhang, Yanmin
2007-12-03 10:05 ` Ingo Molnar
2007-12-04 6:40 ` Zhang, Yanmin
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=20071203095719.GA23106@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=yanmin_zhang@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox