From owner-freebsd-smp Mon Jul 2 9:43: 7 2001 Delivered-To: freebsd-smp@freebsd.org Received: from a.mx.everquick.net (a.mx.everquick.net [216.89.137.3]) by hub.freebsd.org (Postfix) with ESMTP id 2843F37B401 for ; Mon, 2 Jul 2001 09:43:02 -0700 (PDT) (envelope-from eddy+public+spam@noc.everquick.net) Received: from localhost (eddy@localhost) by a.mx.everquick.net (8.10.2/8.10.2) with ESMTP id f62Ggqc14662; Mon, 2 Jul 2001 16:42:52 GMT X-EverQuick-No-Abuse: Report any e-mail abuse to Date: Mon, 2 Jul 2001 16:42:51 +0000 (GMT) From: "E.B. Dreger" To: "Michael C . Wu" Cc: Alfred Perlstein , smp@FreeBSD.ORG Subject: Re: per cpu runqueues, cpu affinity and cpu binding. In-Reply-To: <20010702093638.B96996@peorth.iteration.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org (thoughts from the sidelines) > Date: Mon, 2 Jul 2001 09:36:38 -0500 > From: Michael C . Wu > First of all, we have two different types of processor affinity. > 1. user specified CPU attachment, as you have implemented. > 2. system-wide transparent processor affinity, transparent > to all users, which I see some work below. > > In SMPng, IMHO, if we can do (2) well, a lot of the problems > in performance can be solved. Not just keeping a given process on the same CPU... but what about a "process type"? i.e., if different processes have the same ELF header, run them _all_ on the CPU _unless_ it leaves another CPU excessively idle. Why waste [code] cache on multiple processors when you can keep things on one? > Another problem is the widely varied application that we have. > For example, on a system with many many PCI devices, (2)'s implementation > will be very different from a system that is intended to run > an Oracle database or a HTTP server. Could you please elaborate? > I don't think doing per-thread affinity is a good idea. Because > we want to keep threads lightweight. !!! > You may want to take a look at this url about processor affinity: :) > http://www.isi.edu/lsam/tools/autosearch/load_balancing/19970804.html So many of those links are 404. :-( > An actual empirical measurement is required in this case. > When can we justify the cache performance loss to switch to another > CPU? In addition, once this process is switched to another CPU, > we want to keep it there. Unless two processes are running on CPU #1, and CPU #2 becomes idle. Then switching a process to CPU #2 makes sense... unless the process getting switched is "close" to completion. I'll probably get flamed for suggesting something so ugly, but should we assume that non-daemon processes are short-running, and be more resistant to switching CPUs on those? Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to , or you are likely to be blocked. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message