Messages in this thread | | | Date | Tue, 8 Apr 2003 22:19:45 +0200 | From | Antonio Vargas <> | Subject | Re: fairsched + O(1) process scheduler |
| |
On Tue, Apr 08, 2003 at 02:56:34PM -0400, Hubertus Franke wrote: > > Antonio, while you are coding here is some additional input.
Great!
> By intoducing the user based pending queue and leaking > the tasks back into the runqueue based on the per user ticks, you > are changing semantics slightly. > > If the task is reinserted back into the runqueue oit should be > reinserted into the expired queue iff and only no > expired/active queue switch has happened. > Otherwise it should be reinserted into the active list.
This sounds right :)
> This will becoe important when we later distinguish between > users that have limited share and those that have unlimited.
Yes, we should push the "p->user->uid == 0" test into the send_task_to_user() function then... and later on implement a "p->user->unlimited_cpu_share == 1" test.
> Can be implemented by keeping a per runqueue array switch count > and store it with the pending task. On reinsertion, if > the task has the same as the current it goes to the expired. > If its older than the current, then the task missed the array switch > and it should go into the active queue. > > Also, I don't follow necessarily your reason to put an INTERACTIVE > task back on the active queue immediately, rather than going first > through the pending queue again. > > This way, a high priority job with even a small sleep_avg already being > declared INTERACTIVE, will continue to suck up cycles beyond its > user's limits. This can be as long as 8 secs currently.
Perhaps I'm not declaring this in any explicit way, but I feel that this type of control should only be applied to cpu hogs.
> Instead, things to consider is to feed these as well through the > pending queue and distinguish in the pending queue ? > More thoughts required here... I let you know when any of them is > successful at my end.
I'm somewhat deadlocked right now, so I'll have to wait until I have some think up some way to make it work as intended.
Greets, Antonio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |