Re: cvs commit: src/sys/kern sched_ule.c

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"