From owner-freebsd-smp Thu Dec 10 17:51:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA24049 for freebsd-smp-outgoing; Thu, 10 Dec 1998 17:51:32 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA24035; Thu, 10 Dec 1998 17:51:24 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id SAA17023; Thu, 10 Dec 1998 18:51:16 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp01.primenet.com, id smtpd016818; Thu Dec 10 18:51:09 1998 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id SAA09778; Thu, 10 Dec 1998 18:50:46 -0700 (MST) From: Terry Lambert Message-Id: <199812110150.SAA09778@usr09.primenet.com> Subject: Re: Pthreads and SMP To: mal@algonet.se (Mats Lofkvist) Date: Fri, 11 Dec 1998 01:50:46 +0000 (GMT) Cc: tlambert@primenet.com, alk@pobox.com, peter@netplex.com.au, gpalmer@FreeBSD.ORG, marcelk@stack.nl, smp@FreeBSD.ORG In-Reply-To: <199812102103.WAA24473@kairos.algonet.se> from "Mats Lofkvist" at Dec 10, 98 10:03:44 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The problem with kernel threads is that, barring everything else, > the threads will migrate randomly between processors, cache-busting > as they go, and you won't get significant benefit from having > multiple processors at all. Only multiple processes really gain > benefit from SMP given the current scheduler. > > (Sorry for the delay, but I have been thinking about this > on and off for a few days now and I still don't get it :-) > > Are you saying that processes migrating randomly between processors, > cache busting as they go, is less of a problem for a given parallell > application than kernel threads doing the same? Or that the scheduler > is able to keep processes mostly on the same processor but would not > easily be made able to do the same for kernel threads? The latter, and not on purpose, but merely as an artifact of how the scheduler works. You can get process migration, but it just doesn't happen very often in practice. The use of a (mostly) shared VM space between kernel threads is a major source of cache line invalidation/update and IPI's between the processors in an SMP system, and this adds to the problem. Seperate processes would not require invalidation,/update since the address space is only in one cache at a time, not two. It's an interesting problem. The limits that everyone quotes for scalability of SMP (4 or 8 processors) are really artifacts of interprocessor contention traffic getting to the point it may exceed the "useful" traffic of actually getting work done. A number of smart people at companies like Sequent resolved these problems for 32 (or more) processors years ago, using per processor resource pools and CPU affinity. It looks like a lot of "modern" threading architecture is about to undo a lot of good work in this area by glomming the contention domain back into one unit (the multithreaded process) once again. 8-(. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message