Messages in this thread | ![/](/images/icornerl.gif) | | Date | Wed, 2 Apr 2003 00:19:27 +0200 | From | Antonio Vargas <> | Subject | Re: fairsched + O(1) process scheduler |
| |
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/
| ![\](/images/icornerr.gif) |