From owner-freebsd-threads@FreeBSD.ORG Thu Apr 17 01:31:23 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B70FC37B401 for ; Thu, 17 Apr 2003 01:31:23 -0700 (PDT) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE67743F75 for ; Thu, 17 Apr 2003 01:31:22 -0700 (PDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h3H8VIO57781; Thu, 17 Apr 2003 04:31:18 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Date: Thu, 17 Apr 2003 04:31:18 -0400 (EDT) From: Jeff Roberson To: Julian Elischer In-Reply-To: Message-ID: <20030417042350.X76635-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: Patches for threads/scheduler abstraction. X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2003 08:31:24 -0000 On Wed, 16 Apr 2003, Julian Elischer wrote: > > > > > > > > My plan is: > > > eventually, sched_4bsd.c will only do the original BSD > > > scheduling (except with threads instead of procsses) > > > i.e. unfair, but simple and easy to benchmark on non-threaded apps. > > > (or on threaded apps with no competing processes) > > > > > > sched_4bsd_kse.c will suck in the current contents of kern_switch.c > > > and the KSE'd version of sched_4bsd.c. > > > > > > this will act like the current 4bsd scheduler WITH KSEs > > > > > > > There is a better way to do this. If you would listen to my tiered > > approach you could end up with one copy of sched_4bsd and not two. > > The kse specific logic could just sit in kern_kse which would not > > tell sched_4bsd about threads until they owned the KSE. We could > > even do this without the kse structure as a go between. > > I think that is an overcomplication. > the two BSD based files would be very different. It's not an overcomplication. The two tasks are independent. > For a start the simple one would be queueing threads on the run queues. > A system compiled with that scheduelr would have no KSEs anywhere > in the entire kernel. > The kse one would be queueing KSEs. I don't see how you can do this > with a shared file. You're missing the point. The scheduler shouldn't be tied to the threading implementation. The threading implementation can pick a KSE to run, assign that thread to the KSE, and then set that thread runnable with the scheduler. If it later decides that the KSE should be running something else it can remove the thread currently assigned to it from the scheduler and then reassign the KSE and add the new thread to the scheduler, which places it on the run queue. This way you will not duplicate code and you will keep the two tasks independant. Essentially the sched_*.c files decide system scope contention while the threading implementation determines the process scope contention which may include some concurrency limits imposed by KSE or some other structure. Do you see? This way we could get KSEs out of the entire kernel other than kern_kse.c and still support them with the sched_4bsd and sched_ule scheduler. Otherwise we're going to have a copy of each scheduler for each threading implementation and we wont be able to support two threading implementations simultaneously. > Anyhow, the following hack (totaly unoptimised.... notice the I think this describes the whole project so far. > existance of sched_td_exit, sched_exit_thread, and sched_thr_exit.. > I just haven't got to cleaning it) is not so advanced that > the question of tiered schedulers is relevant yet.. > this patch just shows that it is possible to get the KSEs > out of the rst of the system. > > > > > > switch.c will go away (unless you want it as part of ULE). > > > > > > kern_thread.c will forget all about KSEs > > > (but its not there yet). > > > > > > I'll send the patches in an hour or so.. > > > My wife's calling :-/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Julian > > > > > > > > > > > > > > > > > > > > > > > > > >