From owner-freebsd-hackers Sun Jan 17 11:24:49 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA17243 for freebsd-hackers-outgoing; Sun, 17 Jan 1999 11:24:49 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA17238 for ; Sun, 17 Jan 1999 11:24:48 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id LAA51387; Sun, 17 Jan 1999 11:24:38 -0800 (PST) (envelope-from dillon) Date: Sun, 17 Jan 1999 11:24:38 -0800 (PST) From: Matthew Dillon Message-Id: <199901171924.LAA51387@apollo.backplane.com> To: Jason Evans Cc: Matthew Dillon , Terry Lambert , hackers@FreeBSD.ORG Subject: Re: Path to SMP References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :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): : :... : :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 :... There is nothing magic about a supervisor-supervisor context switch, and the overhead of cloning processes exists only because the full struct proc is being duplicated - also not necessary. All we really need is the concept of a 'task' verses 'process'. A process is made up of one or more scheduling entities called 'tasks'. tasks are trivial to create, switch between, and destroy. I think it can be that simple. The problem UNIXs have now is that the scheduling entity is also the resource management entity, so you start to have to go through loops to make it efficient. If interrupts are moved into kernel threads, stack overhead becomes much more predictable so the stack utilization resource might come in at, say, 8K per thread instead of 16K or 32K per thread. Also, you can still implement a semi-synchronous cross-thread call without having to deal with the overhead of a fully-async design. -Matt Matthew Dillon :Jason Evans To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message