Date: Thu, 12 Aug 2004 23:55:49 +0200 From: Eirik Oeverby <ltning@anduin.net> To: Julian Elischer <julian@elischer.org>, current@freebsd.org Subject: Re: Code for review.. threads vs. the scheduler Message-ID: <411BE765.8030100@anduin.net> In-Reply-To: <411ACCDB.9060904@elischer.org> References: <20040808222837.2E72A16A4D3@hub.freebsd.org> <41173194.6020309@elischer.org> <20040811101431.GA11809@rogue.acs-et.com> <411AA2B0.9020900@elischer.org> <411ACCDB.9060904@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer wrote: > > > Here is a version of the diff that is pretty much functionaly equivalent > to the current system (and > almost identical to patches (c) and (d) (*) but it takes it astep > further in that teh struct kse has been > removed from proc.h and made a private structure within each > scheduler. Nothing outside of the 3 files > kern/sched_4bsd, kern/sched_ule.c and kern/kern_switch.c (which is now > included into the schedulers > rather than linked with them) even knows what a struct kse looks like. > > (*) these patches were not widly distributed. > > The patch is available at: > > http://www.freebsd.org/~julian/e.diff > > At this point each scheduler can be alterred almost completely > independently of the other as long as the > fields in the kse that are referenced in the common code in > kern_switch.c are not renamed or removed. > > -where to from here.... > > The next logical step is to move the fields within the thread, and > ksegrp structures that reference kses into > the scheduler specific extensions to these structures so that not even > those references are externally visible. > This would make the queues and lists that are used to hang KSEs off > also private information for the > scheduler, allowing schedulers to have their own private queueing > architectures without having to expose them > to anything external.. > > The NEXT step after that is to move all the fields in the KSE structure > into the thread's scheduler-private > structure (td_sched) and rename it a "kse" to stop the need for massive > mechanical renaming. > Since every thread has one of these, all the KSE allocation code just > vanishes as do the restraints that they > hold on code due to locking requirements etc. sched_ule and sched_4bsd > don't change much at all. > "concurrency control " is switched to use a simple pair of counters. > (available slots and total slots (concurrency) per ksegrp. Except for > that change, even kern_switch.c > remains mostly the same and the KSE structure as we know it has > dissappeared entirely (though > its name is passed to the td_sched structure for diff-reduction > purposes.. > > when this is done we have a scheduler interface that COMPLETELY hides > within it > how and where threads are queued, or in fact if they are queued at all.. > (A Monte-Carlo scheduler may use a completely different scheme based on > probablilistic scheduling..) > > It should also be a lot more reliable and I suspect that the morphing of > the KSE structure into something > that is always a part of the thread MIGHT also fix the Preemption hang > we've been seeing. > > Sched-ule and sched-4bsd can then be experimented on a lot more freely > without worrying about > unintended changes to teh other. Especially if one of the schedulers > takes a complete copy of > kern_switch.c instead of including it.. Indeed a new scheduler can be > added with a single file, > and no other edits, allowing people to experiment with their own > schedulers much more easily. > Hi there, did anyone actually test this patch? Maybe a change of subject line might help get some attention.. I am very tempted to test it, if there is any chance that it might, in its current form, help stabilizing things on -current. Especially with the preemption issues in the back of my head.. /Eirik
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?411BE765.8030100>