It is possible to do something like this in check_preemption ?
delta = curr->fair_key - first->fair_key;
if (delta > ??? [scale it as you wish] ||
(curr->key > first->key) && (curr->wait_runtime > ???
[simple funtion of curr->weight]) )
preempt
Forgive
Ingo Molnar wrote:
* William Lee Irwin III <[EMAIL PROTECTED]> wrote:
On Mon, May 14, 2007 at 12:31:20PM +0200, Ingo Molnar wrote:
please clarify - exactly what is a mistake? Thanks,
The variability in ->fair_clock advancement rate was the mistake, at
least according to my
William Lee Irwin III wrote:
On Mon, May 14, 2007 at 04:52:59PM +0530, Srivatsa Vaddagiri wrote:
Doesn't EEVDF have the same issue? From the paper:
V(t) = 1/(w1 + w2 + ...wn)
Who knows what I was smoking, then. I misremembered the scale factor
as being on the other side of
William Lee Irwin III wrote:
On Mon, May 14, 2007 at 04:52:59PM +0530, Srivatsa Vaddagiri wrote:
Doesn't EEVDF have the same issue? From the paper:
V(t) = 1/(w1 + w2 + ...wn)
Who knows what I was smoking, then. I misremembered the scale factor
as being on the other side of
Ingo Molnar wrote:
* William Lee Irwin III [EMAIL PROTECTED] wrote:
On Mon, May 14, 2007 at 12:31:20PM +0200, Ingo Molnar wrote:
please clarify - exactly what is a mistake? Thanks,
The variability in -fair_clock advancement rate was the mistake, at
least according to my way
It is possible to do something like this in check_preemption ?
delta = curr-fair_key - first-fair_key;
if (delta ??? [scale it as you wish] ||
(curr-key first-key) (curr-wait_runtime ???
[simple funtion of curr-weight]) )
preempt
Forgive me, there
Hi, Srivatsa
I would say in this case, your specifications of these tasks do not
actually give a base for evaluating the fairness. Imagine, when you want
to check if the generated schedule is _fair_ or not, you first have set
up a base which indicates the behavior tasks should have, and
Hi, Srivatsa
I would say in this case, your specifications of these tasks do not
actually give a base for evaluating the fairness. Imagine, when you want
to check if the generated schedule is _fair_ or not, you first have set
up a base which indicates the behavior tasks should have, and
Hi, Ingo
This is the test case that I think worth discuss and it leads me to
find 2 things.
[...] but there are still some nice issues.
Try running 3 chew.c's, then renicing one to -10, starves others for
some seconds while switching prio-level. Now renice it back to 10, it
starves for
Hi, Ingo
I wrote that email in a hurry, therefore might not explain the
problem clearly. However I do think there is a problem for this part,
after I carefully read the code again. Now I want to try again :-)
Hopefully, this time I will do a right job.
Starting from the following code:
Srivatsa Vaddagiri wrote:
On Thu, May 03, 2007 at 10:50:15AM +0200, Ingo Molnar wrote:
- EEVDF concentrates on real-time (SCHED_RR-alike) workloads where they
know the length of work units
This is what I was thinking when I wrote earlier that EEVDF expects each
task will specify
Ingo Molnar wrote:
* Ting Yang <[EMAIL PROTECTED]> wrote:
Authors of this paper proposed a scheduler: Earlist Eligible Virtual
Deadline First (EEVDF). EEVDF uses exactly the same method as CFS to
track the execution of each running task. The only difference between
EEVDF a
Hi, Ingo
This is the test case that I think worth discuss and it leads me to
find 2 things.
[...] but there are still some nice issues.
Try running 3 chew.c's, then renicing one to -10, starves others for
some seconds while switching prio-level. Now renice it back to 10, it
starves
Hi, Ingo
This is the test case that I think worth discuss and it leads me to
find 2 things.
[...] but there are still some nice issues.
Try running 3 chew.c's, then renicing one to -10, starves others for
some seconds while switching prio-level. Now renice it back to 10, it
starves
Ingo Molnar wrote:
* Ting Yang [EMAIL PROTECTED] wrote:
Authors of this paper proposed a scheduler: Earlist Eligible Virtual
Deadline First (EEVDF). EEVDF uses exactly the same method as CFS to
track the execution of each running task. The only difference between
EEVDF and CFS
Srivatsa Vaddagiri wrote:
On Thu, May 03, 2007 at 10:50:15AM +0200, Ingo Molnar wrote:
- EEVDF concentrates on real-time (SCHED_RR-alike) workloads where they
know the length of work units
This is what I was thinking when I wrote earlier that EEVDF expects each
task will specify
Hi, Ingo
I wrote that email in a hurry, therefore might not explain the
problem clearly. However I do think there is a problem for this part,
after I carefully read the code again. Now I want to try again :-)
Hopefully, this time I will do a right job.
Starting from the following code:
Hi, Ingo
This is the test case that I think worth discuss and it leads me to
find 2 things.
[...] but there are still some nice issues.
Try running 3 chew.c's, then renicing one to -10, starves others for
some seconds while switching prio-level. Now renice it back to 10, it
starves for
On Wed, May 02, 2007 at 11:06:34PM +0530, Srivatsa Vaddagiri wrote:
There is also p->wait_runtime which is taken into account when
calculating p->fair_key. So if p3 had waiting in runqueue for long
before, it can get to run quicker than 10ms later.
Virtual time is time from the
Li, Tong N wrote:
Thanks for the excellent explanation. I think EEVDF and many algs alike
assume global ordering of all tasks in the system (based on virtual
time), whereas CFS does so locally on each processor and relies on load
balancing to achieve fairness across processors. It'd achieve
Hi,
As encouraged by some of you, I have started implementing EEVDF.
However, I am quite new in this area, and may not be experienced enough
to get it through quickly. The main problems, I am facing now ,is how
to treat the semantics of yeild() and yield_to(). I probably will throw
a lot
Srivatsa Vaddagiri wrote:
I briefly went thr' the paper and my impression is it expect each task
to specify the length of each new request it initiates. Is that correct?
No, the timeslice l_i here serves as a granularity control w.r.t
responsiveness (or latency depends on how you interpret
Srivatsa Vaddagiri wrote:
I briefly went thr' the paper and my impression is it expect each task
to specify the length of each new request it initiates. Is that correct?
No, the timeslice l_i here serves as a granularity control w.r.t
responsiveness (or latency depends on how you interpret
Hi,
As encouraged by some of you, I have started implementing EEVDF.
However, I am quite new in this area, and may not be experienced enough
to get it through quickly. The main problems, I am facing now ,is how
to treat the semantics of yeild() and yield_to(). I probably will throw
a lot
Li, Tong N wrote:
Thanks for the excellent explanation. I think EEVDF and many algs alike
assume global ordering of all tasks in the system (based on virtual
time), whereas CFS does so locally on each processor and relies on load
balancing to achieve fairness across processors. It'd achieve
On Wed, May 02, 2007 at 11:06:34PM +0530, Srivatsa Vaddagiri wrote:
There is also p-wait_runtime which is taken into account when
calculating p-fair_key. So if p3 had waiting in runqueue for long
before, it can get to run quicker than 10ms later.
Virtual time is time from the task's
Hi, Ingo
My name is Ting Yang, a graduate student from UMASS. I am currently
studying the linux scheduler and virtual memory manager to solve some
page swapping problems. I am very excited with the new scheduler CFS.
After I read through your code, I think that you might be interested
Hi, Ingo
My name is Ting Yang, a graduate student from UMASS. I am currently
studying the linux scheduler and virtual memory manager to solve some
page swapping problems. I am very excited with the new scheduler CFS.
After I read through your code, I think that you might be interested
28 matches
Mail list logo
