[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CANQmPXi=p0WvJ0GofWFSG8Um6trHw3ejwR-TazZyoXm9g-trJQ@mail.gmail.com>
Date: Sun, 17 Jun 2012 16:20:06 +0800
From: Chen <hi3766691@...il.com>
To: linux-kernel@...r.kernel.org
Subject: Re: [PATCH][ANNOUNCE]RIFS-ES Scheduling V1 release.
On Sun, Jun 17, 2012 at 2:24 PM, Mike Galbraith <efault@....de> wrote:
> Destroys may be a bit strong, but it does have it's problems, one being:
> as resource contention increases, so does total sleep.
Sleeper feature(I mean the re-designed sleeper fairness) give too much
resources to the sleep task. They need to wake up with smaller latency
but if they were given too much priority it will be harmful to the
other interactive tasks eg. X. Under high IO load the sleeper fairness
feature can causes music lag or X lag. We can't remove it since there
is no any tuning to turn this off from 2.6.31.
CFS can still be simplified and optimised.
RIFS-ES uses different way to do this.
if((p->state != TASK_RUNNING) || (p->tick_used >= MAX_TICK_USED)) {
p->tick_used /= 2;
}
Here, an cpu intensive task won't be punished too heavy. also this can
improve the wake up latency of 50+% CPU_BOUND tasks.
if(p->sleep_cnt < MAX_SLEEP_COUNT)
p->sleep_cnt++;
If a task sleep the sleep_cnt increase.
#define prio_raisable(p) ( \
p->prio > ((p->static_prio - reverse(MAX_TICK_USED, p->tick_used)) + \
(p->sleep_cnt / 3)))
Priority of a task that is going to sleep is decided by its time spent
on running. sleep_cnt is the sleep rate of a task.
if(prio_raisable(p))
p->prio--;
if(sleep_jiffy != p->sleep_jiffy)
p->sleep_cnt /= 2;
p->sleep_jiffy = sleep_jiffy;
With this, if the sleep rate of a task is low, the sleep rate will be
divide by 2 and it can wake up with a lower latency.
That is the reason why I call this scheduler RIFS-ES.(RIFS and
enhancement of Unix System V scheduling).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists