cvs commit: src/sys/kern sched_ule.c
Julian Elischer
julian at elischer.org
Mon Dec 13 14:03:31 PST 2004
Julian Elischer wrote:
>
>
> Jeff Roberson wrote:
>
>> On Mon, 13 Dec 2004, Julian Elischer wrote:
>>
>>
>>
>> Why don't we move the ke_procq into the thread and then kern_switch can
>> remain with the generic runq code? Then we can move *runqueue into the
>> individual schedulers. At least then we won't have to make a copy of
>> the
>> bit twiddling code.
>>
>
> hmm just noticed that both 4bsd and ule have kse structure (td_sched)
> fields
> that are not used any more. (e.g. ke_kglist, ke_kgrlist)
>
> The bit twiddling code is already separate in runq.c is it not?
> The fact that finctions in kern_switch are currently used by both BSD
> and ULE
> doesn'rt make them "generic" from my perspective. The are just shared for
> historical reasons. runq_remove and runq_add (for example) ar epretty
> generic but would still need changing if a thread were on >1 list.
having said this we could always migrate the functions one at a time,
starting with
*runqueue.
Here's what I'd do a a compromise..
leave the fields as they are now, (maybe move td_runq).
move any functions to teh schedulers that allow you to clean up and
simplify the schedulers.
(e.g. by merging/inlining functions etc.).
see what's left.
discuss it again.
>
>
> setrunqueue() and remrunqueue() are heavily based on what fairness
> method is used. I'm not happy with the SLOTS as the ultimate answer,
> only as the easiest (except for "ignore fairness"). Having them
> generic limits wow this might be changed. Certainly if ULE were to
> implement
> a smarter fairness method it's need to have its own copy of them.
>
> Re. moving ke_procq. (should be renamed to ke_runq_entry or somrthing)
> What if a scheduler wants to keep a thread on TWO lists..
> Puting it int he scheduler independent part of teh thread structure
> makes this
> harder to do.
>
> For example, I would like to experiment with a version of the BSD
> scheduler that keeps a
> thread on BOTH teh percpu queue and an independent queue.
> it gets removed from both when selected, but suelction is done from
> teh pcpu queue
> first, and proceeds to teh general queue only if there is nothing for
> that cpu.
>
> Another example would be a scheduler that uses (I forget the propper
> name)
> probablity scheduling rather than run queues. it would require a
> completely differnt set of
> fields to represent it's internal structures. Having an externally
> visible run queue
> would be misleading because it would be visible but not used.
>
> I would actually go the other way..
> td_runq should be moved to the td_thread as it is used by the fairness
> code only and that could be implemented completely differently by
> different schedulers. I left it where it was only for diff reduction
> reasons.
>
> Is there a real reason that the two scheduelrs should not have separate
> copies of this code other than diskspace? I think that maintainance
> might even be
> made easier if people maintaining them don't have to always bare in mind
> the fact that the code is being used in two different scenareos with
> very different
> frameworks around them.
>
>
>
> julian
>
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to
> "freebsd-current-unsubscribe at freebsd.org"
More information about the freebsd-current
mailing list