Date: Mon, 2 Jul 2001 17:13:47 +0000 (GMT) From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> To: "Michael C . Wu" <keichii@peorth.iteration.net> Cc: Alfred Perlstein <bright@sneakerz.org>, smp@FreeBSD.ORG Subject: Re: per cpu runqueues, cpu affinity and cpu binding. Message-ID: <Pine.LNX.4.20.0107021704190.15021-100000@www.everquick.net> In-Reply-To: <20010702115044.C99436@peorth.iteration.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Mon, 2 Jul 2001 11:50:44 -0500 > From: Michael C . Wu <keichii@iteration.net> > | 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? > > Because it is very difficult to worry about these things. And the > performance gain might probably be less than the overhead of comparing > the headers. ELF headers was just one example; I'd have to look at the format to get a more specific idea. There are probably other ways to compute a quick, "unique enough" hash. > Different situations require completely different things. > Sometimes a router will have many interrupts for ether device > management. And sometimes we have single purpose servers that only does > one thing. Of course. But the principles are more or less the same... we have multiple processes that we need to distribute on multiple CPUs. What changes is how hard we should resist switching. > | > I don't think doing per-thread affinity is a good idea. Because > | > we want to keep threads lightweight. > | > | !!! > > Please elaborate. I don't understand what three exclamation marks > are supposed to mean. Definitely want lightweight threads. > | 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. > > Please read my post again, I think I explained the idea that > L1 will be busted very quickly. Yes, it will. My [oversimplified as it was] point was that there are times where it's better to wipe out even the L2 cache than it is to have an underutilized processor. 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 <blacklist@brics.com> 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 <blacklist@brics.com>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.20.0107021704190.15021-100000>