From owner-freebsd-smp Sun Dec 6 10:09:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA20894 for freebsd-smp-outgoing; Sun, 6 Dec 1998 10:09:29 -0800 (PST) (envelope-from owner-freebsd-smp@FreeBSD.ORG) Received: from ns1.adsu.bellsouth.com (ns1.adsu.bellsouth.com [205.152.173.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id KAA20888; Sun, 6 Dec 1998 10:09:21 -0800 (PST) (envelope-from ck@ns1.adsu.bellsouth.com) Received: (from ck@localhost) by ns1.adsu.bellsouth.com (8.9.1a/8.9.1) id NAA03200; Sun, 6 Dec 1998 13:09:18 -0500 (EST) Message-ID: <19981206130918.I24178@ns1.adsu.bellsouth.com> Date: Sun, 6 Dec 1998 13:09:18 -0500 From: Christian Kuhtz To: Gary Palmer , Michael Galassi Cc: Marcel van Kervinck , smp@FreeBSD.ORG Subject: Re: Pthreads and SMP References: <199812061719.JAA51729@percy.xyz.com> <52125.912965341@gjp.erols.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <52125.912965341@gjp.erols.com>; from Gary Palmer on Sun, Dec 06, 1998 at 12:29:01PM -0500 Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Dec 06, 1998 at 12:29:01PM -0500, Gary Palmer wrote: > Michael Galassi wrote in message ID > <199812061719.JAA51729@percy.xyz.com>: > > Unless I'm wearing serious blinders I fail to see this as a real > > problem. Unless you have only a tiny number of procs on the system it > > would seem like keeping related threads together would be a good > > thing. If you had multiple closely related threads on seperate procs > > and they decided to acctually access their shared data I'm guessing > > you would see a lot of cache thrashing. > > Then your threaded program is badly designed :) I agree. > Seriously, there are advantages to thread migration and disadvantages. I > believe Solaris only does thread migration when the CPU that the process is on > is overcomitted. So unless you were totally CPU bound (in which case the > process shouldn't have been threaded anyhow, as threads get their advantage > from being I/O or network bound), there shouldn't really be a problem... If you have n CPUs, and n threads in a given process, each CPU bound, it may still make for better application design to have the process be threaded than to have descrete processes running. Suggested reading includes the various papers and books on Mach ukernels. It also depends tremendously on the actual multiprocessor architecture (shared memory, distributed memory etc etc) as much as the application design to make a final judgement call. Regardless, there should be a way to bind any given process or thread to a particular CPU manually, like the Slowlaris pbind command utility. Cheers, Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message