From owner-freebsd-hackers Sun Feb 14 20:10:30 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA26661 for freebsd-hackers-outgoing; Sun, 14 Feb 1999 20:10:30 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA26656 for ; Sun, 14 Feb 1999 20:10:29 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA12131; Sun, 14 Feb 1999 20:10:27 -0800 (PST) (envelope-from dillon) Date: Sun, 14 Feb 1999 20:10:27 -0800 (PST) From: Matthew Dillon Message-Id: <199902150410.UAA12131@apollo.backplane.com> To: Jaye Mathisen Cc: hackers@FreeBSD.ORG Subject: Re: Processor affinity? References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :Noticed somethign a little odd with a 3.1-stable supped a few days ago. : :There were only 3 processes of any significance running on a dual :processor P6. : :mysql, top, and a perl script pumping kazillions of small records into the :mysql database. : :The perl script was basically burning 99.9% of the CPU. Mysql was chewing :up 40-60% of the CPU. : :For some reason that on the suface does not make sense to me, the perl :script moved back and forth among the CPU's, just about like clockwork, :every update or so of top. : :This seems odd to me, in that given the size of the program (small), and :the amount of CPU burning, it would be better if the perl process stayed :stuck to 1 CPU to maximise the use of the cache (512k) of that CPU, :instead of having to wander around. : :Is there some way to set processor affinity on a process? Or some tweak :to some sysctl variable somewhere that I can take advantage of? Doing processor affinity properly is very difficult. It isn't as simple as trying to keep a process on a specific cpu. Whatever algorithm is chosen must deal with the situation under a greater process load. Often, as on IRIX 6.1 boxes, affinity could make things worse rather then better by unbalancing the cpu's. Processor affinity makes sense when you have a lot of processors ( you can schedule a process to a group of cpu's to maintain reasonable balancing across the system), but doesn't make much sense if you only have 2-4. Note that processor affinity scheduling is different from hard-assigning a process to a processor. Even so, there are very few circumstances where even hard-assigning will do a better job then letting the scheduler do it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message