From owner-freebsd-smp Wed Oct 2 13:02:55 1996 Return-Path: owner-smp Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id NAA02319 for smp-outgoing; Wed, 2 Oct 1996 13:02:55 -0700 (PDT) Received: from friley216.res.iastate.edu (friley216.res.iastate.edu [129.186.78.216]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id NAA02281 for ; Wed, 2 Oct 1996 13:02:13 -0700 (PDT) Received: from friley216.res.iastate.edu (loopback [127.0.0.1]) by friley216.res.iastate.edu (8.7.6/8.7.3) with ESMTP id OAA00385; Wed, 2 Oct 1996 14:49:38 -0500 (CDT) Message-Id: <199610021949.OAA00385@friley216.res.iastate.edu> To: Peter Wemm cc: freebsd-smp@freebsd.org Subject: Scheduling and idle loops.. (Was Re: cvs commit: sys/kern . . ) In-reply-to: Your message of Wed, 02 Oct 1996 12:07:11 -0700. <199610021907.MAA28520@freefall.freebsd.org> Date: Wed, 02 Oct 1996 14:49:37 -0500 From: "Chris Csanady" Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >peter 96/10/02 12:07:10 > > Modified: kern init_main.c > i386/i386 mpboot.s > Log: > Kill some NCPU == 2 dependencies. > > Theoretically, it can now run 'n' cpus (n < 15). It creates as many > idle procs as are needed, and carefully brings them online so that it > can reuse mp_stk each time. I've not looked very closely, but I think > most other places in the code deal with 'NCPU'. I'll check soon. > It uses a new type of mutex semaphore for unlocking the cpus, as suggested > in some intel docs. Should we perhaps set the var hw.ncpu early on, and get rid of the NCPU config variable? It seems to be there for nothing right now.. > > Also... shudder.. It fires up the alternate cpus as soon as the idle proc > is scheduled, ie: at boot time immediately after init. No more need to > set kern.smp_active to 2. In theory, if you have 4 cpus, smp_active should > end up with the value "4". Raising and lowering it will probably enable and > disable the appropriate numbered cpus. Setting smp_active to 1 should cause > the system to effectively run uniprocessor. On this topic, the smp.todo mentions we want to get rid of the idle processes?! I have been looking at the scheduling code, and although I am currently somewhat confused, it does not seem that this would be possible until we have a threaded kernel. Am I incorrect in assuming this? the current idle loop in the UP code is in the kernel, so it doesnt seem as if we could do it that way without some degree of threading. More generally though, Is anyone looking at rewriting the scheduler? And based upon what? I was going to try and work on this, but currently, I havent gotten a complete understanding of everything going on, and how to go about it the right way. I dont know.. perhaps I should just stay away from some stuff. :) Chris Csanady > > "It works for me (TM)".. > > Revision Changes Path > 1.24 +63 -40 sys/kern/init_main.c > 1.4 +30 -8 sys/i386/i386/mpboot.s