Date: Sun, 31 Jan 1999 00:30:47 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: dyson@iquest.net Cc: tlambert@primenet.com, dillon@apollo.backplane.com, wes@softweyr.com, toasty@home.dragondata.com, hackers@FreeBSD.ORG Subject: Re: High Load cron patches - comments? Message-ID: <199901310030.RAA26908@usr04.primenet.com> In-Reply-To: <199901300929.EAA59052@y.dyson.net> from "John S. Dyson" at Jan 30, 99 04:29:32 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901310030.RAA26908>