Date: Sun, 17 Jan 1999 01:51:55 -0800 (PST) From: Jason Evans <jasone@canonware.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Terry Lambert <tlambert@primenet.com>, hackers@FreeBSD.ORG Subject: Re: Path to SMP Message-ID: <Pine.BSF.4.05.9901170057230.27422-100000@sturm.canonware.com> In-Reply-To: <199901170641.WAA46889@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon initially asked: > Is anyone currently working on the next big step in the SMP > puzzle? That is, implementing kernel threads with preemptive > scheduling? Matthew Dillon continued on to infer that this is all that is necessary in order to have good SMP support for threaded applications (assuming the Linux definition of kernel threads): > The idea being that one then has the ability to run > preemptable kernel threads in parallel on SMP-capable > boxes because the code must assume preemption in the > same manner on both uni and multi cpu systems. > > Once implemented, we would begin to migrate functionality > from non-preemptive threads to preemptive threads from > the outside-in, and parallel SMP operation in supervisor > mode migrates along with it. Terry Lambert replied: :Jason Evans has started work on an async call based mechanism. : [...] Matthew Dillon replied: > This sounds like it is solving a different problem. It would be > a rather complex solution to a relatively simple problem - processes > can already 'almost' run in supervisor mode, in parallel, in an SMP > environment. Actually, I don't think it's enough to have the ability to run multiple "clone()d" processes in supervisor mode, in parallel. The problem is that these processes can block in the kernel. For an N->M mapping of threads->processes, this means a process can block, thus preventing other schedulable user threads from running. In the LinuxThreads model, every user thread is associated with a clone()d process, but this doesn't scale well, and has the additional problem of slow thread context switches (despite what Linux users claim about their fast kernel context switching being good enough). Solaris goes to great lengths to deal with this problem. It has to make sure that there is always an extra LWP available if it wants to always be able to schedule threads on idle processors, even if all of its other LWP's are blocked in the kernel. The complexity associated with this approach is staggering. You don't even want to know how they do it. =( The asynchronous system call mechanism allows a simpler solution, and appears to me to achieve the same level of flexibility and similar performance to the Solaris solution. The idea is to have a pool of kernel thread (not the Linux definition) contexts that can be used to execute asynchronous system calls. The kernel never has to worry in advance about running out of contexts, since it can always create more on the fly. So, as I see it, this doesn't solve a different problem than you originally brought up; it goes the final step in solving the problem of creating truly good support for threaded applications, both for SMP and UP machines. Jason Jason Evans <jasone@canonware.com> http://www.canonware.com/~jasone Home phone: (650) 856-8204 Work phone: (415) 808-8742 "I once knew a happy medium. Her name was Zohar." - James Foster To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9901170057230.27422-100000>