lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-Id: <475BEE6B.BA47.005A.0@novell.com> Date: Sun, 09 Dec 2007 13:32:27 -0500 From: "Gregory Haskins" <ghaskins@...ell.com> To: "Dmitry Adamushko" <dmitry.adamushko@...il.com>, "Steven Rostedt" <srostedt@...hat.com> Cc: "Peter Zijlstra" <a.p.zijlstra@...llo.nl>, "Ingo Molnar" <mingo@...e.hu>, "Balbir Singh" <balbir@...ibm.com>, <vatsa@...ux.vnet.ibm.com>, "LKML Kernel" <linux-kernel@...r.kernel.org> Subject: Re: RT Load balance changes in sched-devel Hi Dmitry, >>> On Sun, Dec 9, 2007 at 12:16 PM, in message <b647ffbd0712090916l4eb9a944r4726680a5fdcae46@...l.gmail.com>, "Dmitry Adamushko" <dmitry.adamushko@...il.com> 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 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