Date: Mon, 13 Dec 2004 14:03:30 -0800 From: Julian Elischer <julian@elischer.org> To: Julian Elischer <julian@elischer.org> Cc: Stephan Uphoff <ups@tree.com> Subject: Re: cvs commit: src/sys/kern sched_ule.c Message-ID: <41BE11B2.5060300@elischer.org> In-Reply-To: <41BE0EB3.8010003@elischer.org> References: <200412131309.iBDD9XXi045169@repoman.freebsd.org> <20041213082407.U9536@mail.chesapeake.net> <41BDDD5E.9060308@elischer.org> <41BDE477.5050103@freebsd.org> <41BDEAD1.9060308@elischer.org> <20041213152556.R60504@mail.chesapeake.net> <41BE0EB3.8010003@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41BE11B2.5060300>