On Tue, Apr 01, 2003 at 08:41:26AM -0800, William Lee Irwin III wrote:
> On Tue, Apr 01, 2003 at 02:51:59PM +0200, Antonio Vargas wrote:
> +
> + if(fairsched){
> + /* special processing for per-user fair scheduler */
> + }
>
> I suspect something more needs to happen there. =)
:) I haven't even compiled with this patch, I'm just trying
to get around my ideas and thus I posted so that:
a. We had an off-site backup
b. People with experience could shout out loud if they saw
some big-time silliness.
> I'd recommend a different approach, i.e. stratifying the queue into a
> user top level and a task bottom level. The state is relatively well
> encapsulated so it shouldn't be that far out.
>
>
> -- wli
I suspect you mean the scheduler runqueues?
My initial idea runs as follows:
a. On each array switch, we add some fixed value
to user->ticks. (HZ perhaps?)
b. When adding, we cap at some maximum value.
(2*HZ perhaps?)
c. On each timer tick, we decrement current->user->ticks.
d. When decrementing, if it's below zero we just
end this thread. (user has expired)
e. When switching threads, we take the first one that belongs
to a non-expired user. I think this can be done by sending
the user-expired threads to the expired array, just like
when they expire themselves.
I'll try to code this tonight, so I'll post later on
if I'm lucky.
I think this needs much less complexity for a first version,
but I would try what you propose if I get intimate enough
with the scheduler.
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/
This archive was generated by hypermail 2b29 : Mon Apr 07 2003 - 22:00:15 EST