Date: Fri, 11 Dec 1998 01:50:46 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mal@algonet.se (Mats Lofkvist) Cc: tlambert@primenet.com, alk@pobox.com, peter@netplex.com.au, gpalmer@FreeBSD.ORG, marcelk@stack.nl, smp@FreeBSD.ORG Subject: Re: Pthreads and SMP Message-ID: <199812110150.SAA09778@usr09.primenet.com> In-Reply-To: <199812102103.WAA24473@kairos.algonet.se> from "Mats Lofkvist" at Dec 10, 98 10:03:44 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812110150.SAA09778>