Date: Thu, 11 Nov 1999 23:56:30 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Ben Rosengart <ben@skunk.org> Cc: Kip Macy <kip@lyris.com>, Assar Westerlund <assar@sics.se>, hackers@FreeBSD.ORG Subject: Re: make -jN world; how to determine optimal value of N? Message-ID: <Pine.BSF.3.96.991111235239.39039A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.20.9911111912290.99311-100000@penelope.skunk.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Nov 1999, Ben Rosengart wrote: > On Thu, 11 Nov 1999, Kip Macy wrote: > > > That is the same specious logic that is used for Linux's "threads" you > > have diminishing marginal returns as the number gets larger due to context > > switching overhead. > > Diminishing *marginal* returns I can live with, but I wonder if this > strategy is actually hurting me, rather than merely failing to help > much. > > Once I get a scratch box that I can waste on things like this, I'll run > some tests and find out. Well, presumably at some point your memory working set exceeds your CPU cache, and that begins to hurt. And then at some point your working memory pages exceed the available space, and you begin to page. Also, your working file block set exceeds your buffer cache, etc. Of course, with more outstanding disk requests, you give the hard disk driver and disk hardware itself more time to optimize seek patterns, but that probably doesn't make up for the increase in I/O based on not keeping as much in memory :-). Where your peak is probably depends primarily on how many processes you can fit into your physical memory, and the disk working set compared to throughput of the processes. This is all just speculation as I haven't done timings, but you should certainly see a drop in performance when N is too high :-). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.991111235239.39039A-100000>