On 01/10/2007, Ingo Molnar <[EMAIL PROTECTED]> wrote:
> 
> * Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> 
> > here is a few patches on top of the recent 'sched-dev':
> >
> > (1) [ proposal ] make timeslices of SCHED_RR tasks constant and not
> > dependent on task's static_prio;
> >
> > (2) [ cleanup ] calc_weighted() is obsolete, remove it;
> >
> > (3) [ refactoring ] make dequeue_entity() / enqueue_entity()
> > and update_stats_dequeue() / update_stats_enqueue() look similar, 
> > structure-wise.
> 
> thanks - i've applied all 3 patches of yours.
> 
> > (compiles well, not functionally tested yet)
> 
> (it boots fine here and SCHED_RR seems to work - but i've not tested
> getinterval.)

/me is guilty... it was a bit broken :-/ here is the fix.

results:

(SCHED_FIFO)

[EMAIL PROTECTED]:~/storage/prog$ sudo chrt -f 10 ./rr_interval 
time_slice: 0 : 0

(SCHED_RR)

[EMAIL PROTECTED]:~/storage/prog$ sudo chrt 10 ./rr_interval 
time_slice: 0 : 99984800

(SCHED_NORMAL)

[EMAIL PROTECTED]:~/storage/prog$ ./rr_interval 
time_slice: 0 : 19996960

(SCHED_NORMAL + a cpu_hog of similar 'weight' on the same CPU --- so should be 
a half of the previous result)

[EMAIL PROTECTED]:~/storage/prog$ taskset 1 ./rr_interval 
time_slice: 0 : 9998480


Signed-off-by: Dmitry Adamushko <[EMAIL PROTECTED]>

---
diff --git a/kernel/sched.c b/kernel/sched.c
index d835cd2..cce22ff 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -4745,11 +4745,12 @@ long sys_sched_rr_get_interval(pid_t pid, struct 
timespec __user *interval)
        else if (p->policy == SCHED_RR)
                time_slice = DEF_TIMESLICE;
        else {
+               struct sched_entity *se = &p->se;
                unsigned long flags;
                struct rq *rq;
 
                rq = task_rq_lock(p, &flags);
-               time_slice = sched_slice(&rq->cfs, &p->se);
+               time_slice = NS_TO_JIFFIES(sched_slice(cfs_rq_of(se), se));
                task_rq_unlock(rq, &flags);
        }
        read_unlock(&tasklist_lock);

---



-
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/

Reply via email to