From owner-freebsd-smp Sat Jan 22 19:42: 7 2000 Delivered-To: freebsd-smp@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9712214BE9 for ; Sat, 22 Jan 2000 19:42:04 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id UAA08573; Sat, 22 Jan 2000 20:05:57 -0800 (PST) Date: Sat, 22 Jan 2000 20:05:57 -0800 From: Alfred Perlstein To: scip7050@programmer.net Cc: smp@FreeBSD.ORG Subject: Re: kernel thread issue Message-ID: <20000122200557.B26520@fw.wintelcom.net> References: <0001222157425P.27824@weba1.iname.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <0001222157425P.27824@weba1.iname.net>; from scip7050@programmer.net on Sat, Jan 22, 2000 at 09:57:42PM -0500 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * scip7050@programmer.net [000122 19:26] wrote: > Hi! > > I have some questions which I would like some kernel hackers could answer me. > > First, > Why kernel thread cannot be spawned out for SMP case? > The comment written in kern_fork.c said that "cannot have same > PTD on both cpus, the PTD needs to be move out of PTmap and be > per-process". Could anyone explain on this comment? I'm not all that up to speed on 3.x, however what it seems to mean is that the CPUs in 3.x don't share page table descriptors in such a way that makes it possible to safely have two programs sharing them on seperate processors. 4.0 Has fixed this (afaik thanks to Alan Cox), since 4.0 is slated for an upcoming release I wouldn't concern myself with this too much. > > Second, > As I know that most kernel design to support kernel thread, will > have to explicitly define another 'thread' data structure and try > to put scheduling related information and hardware PCB and others > to the thread structure. Yes, this is the way to do it without having ugly things like kthreads polluting the process namespace. > It seems that if the kernel is designed in this way to support > the kernel thread, it makes things more explicitly defned. Yes, Linux does this with 'struct task'. > For instance, Solaris 2.x can even use the kernel thread to > schedule interrupt handler in certain case. Hence it makes the > kernel fully preemptible. The question is what will be the impact > to the kernel if thread data structure is added in and used as the > fundamental active scheduling objects? That's not what makes the kernel fully preemptible, it helps, but it's not the only key you need. As far as seperating processes from tasks, the concepts have already been thought out and discussed thouroughly on the arch- mailing list. You can check it out at: http://www.freebsd.org/support.html#mailing-list searching for 'KSE' will probably give you what you are looking for. Btw, for someone with such insight into the code you ought to have a properly configured mail client. :) please wrap lines at 70 characters. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message