Hi Dmitry, >>> On Sun, Dec 9, 2007 at 12:16 PM, in message <[EMAIL PROTECTED]>, "Dmitry Adamushko" <[EMAIL PROTECTED]> wrote: > [ cc'ed lkml ] > > I guess, one possible load-balancing point is out of consideration -- > sched_setscheduler() > (also rt_mutex_setprio()). > > (1) NORMAL --> RT, when p->se.on_rq == 1 && ! task_running(rq, p) > > (2) RT --> NORMAL, when task_running(rq, p) == 1 > > e.g. for (2) we may even get a completely idle rq (schedule() --> > schedule_balance_rt() will not help due to schedule_balance_rt() > having a rt_task(prev) check in place... and 'prev' is of NORMAL type > when it's scheduled out).
Indeed. I think you are correct on both counts. This is an oversight, so good eyes! > > > btw., both cases would be addressed by placing load-balance points > into sched_class_rt->{enqueue,dequeue}_task_rt()... push_rt_tasks() > and pull_rt_tasks() respectively. As a side effect (I think, > technically, it would be possible), 3 out of 4 *_balance_rt() calls > (the exception: schedule_tail_balance_rt()) in schedule() would become > unnecessary. > > _BUT_ > > the enqueue/dequeue() interface would become less straightforward, > logically-wise. > Something like: > > rq = activate_task(rq, ...) ; /* may unlock rq and lock/return another one > */ > > would complicate the existing use cases. > I think I would prefer to just fix the setscheduler/setprio cases for the class transition than change the behavior of these enqueue/dequeue calls. But I will keep an open mind as I look into this issue. Thanks for the review! -Greg -- 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/