Date: Fri, 22 Jan 1999 23:16:40 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> To: hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change Message-ID: <199901230616.XAA21124@psf.Pinyon.ORG> In-Reply-To: Your message of "Fri, 22 Jan 1999 22:59:27 CST." <199901230459.WAA06844@home.dragondata.com>
next in thread | previous in thread | raw e-mail | index | archive | help
toasty@home.dragondata.com said: %Just boosting artificial priorities up and down doesn't really help. I end %up cutting off processes needlessly, or missing events that I can't afford %to miss. In FreeBSD priorities are mutable. Not sufficient, theoretically. *But*, I am amazed at what runs some of the more ah heavyweight arsenal we (the U.S.) fund. dillon@apollo.backplane.com said: % Guys, guys... when I said 'priority' I simply meant 'some sort % of scheduling mechanism'. I didn't mean 'priority' in the % sense of some arbitrary static number, nor do I infer that % we intentionally block any processes when memory *is* available. Well, why didn't you say so! :-) [...] dyson@iquest.net said: %When looking into alternative scheduling mechanisms, priority just %doesn't describe an adequate solution to the new range of problems %(multimedia scheduling, realtime data, timesharing), that need to be %solved concurrently (perhaps with the same resources.) Why not? :-) Of course not. A single parameter like "priority" won't do it. Application domains need scheduling partitions too. And there is no "GOD" algorithm that fits all. I would suggest that if the scheduler needs to be reworked, to fit at a minimum the kinds of work John lists, that people think about how to provide a framework to plug in various scheduling (process|memory) implementations. uhhhh, ye olde "strategy pattern". Russell 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?199901230616.XAA21124>