From owner-freebsd-smp Sun Jan 23 2: 6:18 2000 Delivered-To: freebsd-smp@freebsd.org Received: from web112.yahoomail.com (web112.yahoomail.com [205.180.60.82]) by hub.freebsd.org (Postfix) with SMTP id 2AFC314D9D for ; Sun, 23 Jan 2000 02:06:14 -0800 (PST) (envelope-from scip7050@yahoo.com) Received: (qmail 18018 invoked by uid 60001); 23 Jan 2000 10:06:13 -0000 Message-ID: <20000123100613.18017.qmail@web112.yahoomail.com> Received: from [137.132.2.109] by web112.yahoomail.com; Sun, 23 Jan 2000 02:06:13 PST Date: Sun, 23 Jan 2000 02:06:13 -0800 (PST) From: Chee Wei Ng Subject: SMP and multithreading To: smp@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! After I have read some of the mails in the "freebsd-arch" mailing list on the topic of threading design issue, I would like to know whether the design has been finalized or not? Beside that, I would like to make few comments on it. (Fix me! if I am wrong) First, SA issue. The idea of this paper is to make multithreading programming to have flexible functionality and have the user thread perfomance. This idea is only used in process context, i.e. the thread must attach to one of the process. This is not applicable to kernel thread which may not have process context as describe in "UNIX Internals [Chap 3. section 3.2.1]". Hence its design may only useful and benefit fine grained multiprogramming in Uni- or Multi- processors. (Use kernel thread to handle interrupt "no proces context" as in Solaris 2.x is another issue which could not be handled in SA). Second, SMP issue. To enable multithreads to run on multiprocessors, the primary thing to do is to design multithreaded (Note: "thread" here refers to kernel thread) MP kernel first. Don't try to mix the UST with the support of kernel thread together first. We can have other supports after we have completed the multitheaded MP kernel. To have the multithreaded MP kernel, code related scheduler runq, sleepq, proc struct and others need to be thoroughly examied as I belive that this could lead to substanstial modfication of the kernel. Other subsystems may be afftected also. Of course, we can still stick to our old model, one process on one processor at any time. There is nothing wrong here! Third, scheduler issue. In order to support MP, the scheduler must redesign (whether to support multithreading or multitasking) to make it scalable and enable to preempt process or thread at more points in kernel mode rather than preempted just at the point out to user mode. Since virtual memory and memory management are derived from Mach VM, I believe that to make the VM MP-safe should have good refernence from Mach code. Oh! by the way where can find the fix for PTD issue, where both CPUs' could not run the same PTD at version 3.3 kernel. Regards, NgCW __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message