From owner-freebsd-hackers Fri Jan 22 22:20:17 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA20932 for freebsd-hackers-outgoing; Fri, 22 Jan 1999 22:20:17 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from psf.Pinyon.ORG (ppp1-141.presc.dialup.futureone.com [209.250.11.141]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id WAA20909 for ; Fri, 22 Jan 1999 22:20:12 -0800 (PST) (envelope-from rcarter@psf.Pinyon.ORG) Received: from psf.Pinyon.ORG (localhost [127.0.0.1]) by psf.Pinyon.ORG (8.9.2/8.9.2) with ESMTP id XAA21124 for ; Fri, 22 Jan 1999 23:16:40 -0700 (MST) (envelope-from rcarter@psf.Pinyon.ORG) Message-Id: <199901230616.XAA21124@psf.Pinyon.ORG> X-Mailer: exmh version 2.0.2 2/24/98 To: hackers@FreeBSD.ORG Subject: Re: Error in vm_fault change In-reply-to: Your message of "Fri, 22 Jan 1999 22:59:27 CST." <199901230459.WAA06844@home.dragondata.com> Mime-Version: 1.0 Content-Type: text/plainTo: current@freebsd.org Date: Fri, 22 Jan 1999 23:16:40 -0700 From: "Russell L. Carter" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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