Date: Mon, 08 Nov 1999 09:41:56 -0800 From: Mike Smith <mike@smith.net.au> To: james.g.mansion@hsbcgroup.com Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Dual Celeron + FreeBSD? Message-ID: <199911081741.JAA19666@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 08 Nov 1999 11:04:41 GMT." <80256823.003D4AD1.00@hbmdtesmtp1.markets.uk.hsbc>
next in thread | previous in thread | raw e-mail | index | archive | help
> > Aside from the various issues about serialised compiling > in some parts of the tree, UDMA vs SCSI bun fight, etc, > I'm interested that you are claiming memory bandwidth is > the bottleneck. Well, when you're no longer talking to any peripherals, memory bandwidth is the only limiting factor. A 'make world' entirely from/to MFS can only be limited by memory bandwidth. > I've seen claims that Intel chips are memory bandwidth > limited for as long as I can remember but the expected > brick walls have been elusive, whatever the very low > level benchmarks say, and the scalability of e.g. SQLServer > and other databases across quads and higher seems quite > good, which is somewhat counter to your suggestion which > as I read it implies that a quad Xeon is already starting to > hit a brick wall for non-trivial (in-cache) code and 8-way > systems are on a hiding to nothing. Er, so what you're saying is that while the low-level benchmarks demonstrate there's a limit, the fact that the high-level benchmarks keep getting faster means that the low-level benchmarks must be wrong? Has it ever occurred to you that the high-level benchmarks might still be limited by other factors? > Is it possible to use the CPUs' counters to measure how > long they spend busy-waiting on the giant lock and record > it somewhere once they enter the kernel itself? Probably. It's certainly demonstrate that we would benefit a lot from more kernel reentrancy in thos particular benchmark. > Is it not the case that even with the lazy write feature turned > on the single threaded kernel (without even a possibility of > a task switch when blocked on entry) will tend to make a > system that is doing a lot of small IOs against a memory-based > file system or cache look CPU or memory bound (from the > lock spins) rather than IO bound? My understanding was > that gcc+binutils compiles are far from optimal in terms of > their IO pattern wrt minimising the number of kernel entries. I'm sure they're not, but we're not talking about optimal performance here, we're talking about the behaviour of a specific code set. > I'd be concerned about pointing the finger at the CPU/memory > interface based on measurements from a system which has > such a busy-wait mechanism, unless there is other supporting > evidence (ideally compute-bound application benchmarks, > rather than low-level memory stress tests). Perhaps I wasn't being clear enough; in the situations I'm considering, the only limiting factor available is memory bandwidth. No, our architecture isn't taking advantage of the parallelism available, but the serialisation points are also limited basically by memory bandwidth. > wrt 'make -j', some of the levels of paralellisation being used > (e.g. Adam Strohl using -j 12) would surely be entirely > counter-productive with soft updates or a memory file system, > since you are more likely to swap, more likely to have a whole > bunch of processes spinning uselessly on the lock, making the > scheduler work harder, and don't actually have much physical > IO time to fill in with computing anyway? You're unlikely to swap in most of these cases, actually. The memory footprint for -j12 builds is surprisingly small, and in my case I'm using a system with 1GB of memory. The scheduler doesn't "work harder", since fortunately our scheduler is fairly close to O(1) in behaviour. But your point about the GKL is quite valid. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ msmith@freebsd.org \\ and he'll hate you for a lifetime. \\ msmith@cdrom.com 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?199911081741.JAA19666>