Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 23 Jan 2000 02:06:13 -0800 (PST)
From:      Chee Wei Ng <scip7050@yahoo.com>
To:        smp@freebsd.org
Subject:   SMP and multithreading
Message-ID:  <20000123100613.18017.qmail@web112.yahoomail.com>

next in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000123100613.18017.qmail>