From owner-freebsd-current@FreeBSD.ORG Thu Aug 12 21:56:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 155F216A4CE for ; Thu, 12 Aug 2004 21:56:02 +0000 (GMT) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id C727043D2D for ; Thu, 12 Aug 2004 21:56:01 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from mailnull by anduin.net with spam-scanned (Exim 4.34; FreeBSD) id 1BvNYG-000Dbw-5K for current@freebsd.org; Thu, 12 Aug 2004 23:56:00 +0200 Received: from [217.8.136.185] (helo=[192.168.1.237]) by anduin.net with esmtp (Exim 4.34; FreeBSD) id 1BvNYA-000Dbj-Jz; Thu, 12 Aug 2004 23:55:55 +0200 Message-ID: <411BE765.8030100@anduin.net> Date: Thu, 12 Aug 2004 23:55:49 +0200 From: Eirik Oeverby User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer , current@freebsd.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> In-Reply-To: <411ACCDB.9060904@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on anduin.net X-Spam-Level: X-Spam-Status: No, hits=0.0 required=7.5 tests=none autolearn=no version=2.63 Subject: Re: Code for review.. threads vs. the scheduler X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2004 21:56:02 -0000 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