From owner-freebsd-hackers Sat Jan 30 16:30:55 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA13423 for freebsd-hackers-outgoing; Sat, 30 Jan 1999 16:30:55 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA13407 for ; Sat, 30 Jan 1999 16:30:54 -0800 (PST) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id RAA23152; Sat, 30 Jan 1999 17:30:53 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp03.primenet.com, id smtpd023133; Sat Jan 30 17:30:51 1999 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id RAA26908; Sat, 30 Jan 1999 17:30:50 -0700 (MST) From: Terry Lambert Message-Id: <199901310030.RAA26908@usr04.primenet.com> Subject: Re: High Load cron patches - comments? To: dyson@iquest.net Date: Sun, 31 Jan 1999 00:30:47 +0000 (GMT) Cc: tlambert@primenet.com, dillon@apollo.backplane.com, wes@softweyr.com, toasty@home.dragondata.com, hackers@FreeBSD.ORG In-Reply-To: <199901300929.EAA59052@y.dyson.net> from "John S. Dyson" at Jan 30, 99 04:29:32 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Throttling fork rate is also a valuable tool, and maybe a hard limit > > > is good also. It is all about how creative you are (or want to be) > > > in your solution :-). > > > > I wonder about an explicit yield being a result of your standard > > fork(2) call invocation... the more processes in read-to-run, the > > longer you get to wait before your next fork... > > If one did that, it would be wise idea to only do the yield when > it would be profitable. Do you mean "only when someone is actually waiting to run", or do you mean "as defined by the results of some as yet undefined profitability calculation"? I think if the penalty for a fork were that you went to the end of the run queue, that would be a Good Thing(tm). Also, remember that after the fork, your child is ready-to-run. So if you explicitly yeilded, the worst case is that your child runs before you run again. It would be a lot more interesting a penalty under a fair share or credential agregate quantum (one John vs. one Terry vs. one Matt) scheduler... Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message