Date: Sat, 30 Jun 2001 04:35:23 +0000 (GMT) From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> To: "Michael C . Wu" <keichii@peorth.iteration.net> Cc: Matthew Rogers <matt@accelnet.net>, freebsd-smp@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: CPU affinity hinting Message-ID: <Pine.LNX.4.20.0106300344310.18448-100000@www.everquick.net> In-Reply-To: <20010629214443.A69846@peorth.iteration.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Fri, 29 Jun 2001 21:44:43 -0500 > From: Michael C . Wu <keichii@iteration.net> > > The issue is a lot more complicated than what you think. How so? I know that idleproc and the new ipending / threaded INTs enter the picture... and, after seeing the "HLT benchmark" page, it would appear that simply doing nothing is sometimes better than doing something, although I'm still scratching my head over that... > This actually is a big issue in our future SMP implementation. I presumed as much; the examples I gave were trivial. I also assume that memory allocation is a major issue... to not waste time with inter-CPU locking, I'd assume that memory would be split into pools, a la Hoard. Maybe start with approx. NPROC count equally-sized pools, which are roughly earmarked per hypothetical process. For example: If MAXUSERS=80 --> NPROC=1300, a machine with 256 MB might use 192 kB initial granularity for mmap() requests, giving 128 MB to each processor as a first approximation. Now, no locking is needed on mmap() until a given CPU's "pool" hits low water, and steals from another pool. This would hopefully be infrequent, particularly assuming that memory allocations would be distributed roughly equally between CPUs. I'm assuming that memory allocations are 1:1 mappable wrt processes. Yes, I know that's faulty and oversimplified, particularly for things like buffers and filesystem cache. > There are two types of processor affinity: user-configurable > and system automated. We have no implementation of the former, Again, why not "hash(sys_auto, user_config) % NCPU"? Identical processes would be on same CPU unless perturbed by user_config. Collisions from identical user_config values in unrelated processes would be less likely because of the sys_auto pertubation. Granted: It Is Always More Complicated. (TM) But for a first pass... > and alfred-vm has a semblance of the latter. Please wait > patiently..... Or, if impatient, would one continue to brainstorm, not expect a response (i.e., not get disappointed when something basic is posted), and track -current after the destabilization? :-) 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.0106300344310.18448-100000>