Date: Mon, 14 Dec 1998 19:27:43 -0000 From: James Mansion <james@westongold.com> To: Terry Lambert <tlambert@primenet.com>, mal@algonet.se Cc: alk@pobox.com, peter@netplex.com.au, gpalmer@FreeBSD.ORG, marcelk@stack.nl, smp@FreeBSD.ORG Subject: RE: Pthreads and SMP Message-ID: <32BABEF63EAED111B2C5204C4F4F5020183A@WGP01>
next in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Terry Lambert [mailto:tlambert@primenet.com] > Sent: Friday, December 11, 1998 1:51 AM >... > > 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. So, in what way is an application built from multiple processes with shared state in a shared memory segment going to be better than an application with multiple kernel threads running in a largely shared address space? Is this simply an artifact of the heap manager being an additional shared data structure that is updated? If the threads run (largely) in thread-specific heaps, and/or the main heap is very thread-aware (likeSmartHeap for SMP, for example) where's the beef? It seems this isn't a complaint about kernel threads per se, but about the negative effects of having much state that is updated by multiple threads and also read frequently, which is a design issue for the MT application. And one that is there for an app built from multiple processes with explicit shared memory, too. James 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?32BABEF63EAED111B2C5204C4F4F5020183A>