* Nick Piggin <[email protected]> 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 <[email protected]>
do more agressive yield for SCHED_BATCH tasks.
Signed-off-by: Ingo Molnar <[email protected]>
---
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'.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
