This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sun May 12 16:36:37 2024 Received: from vger.kernel.org (vger.kernel.org [209.116.70.75]) by kylie.puddingonline.com (8.11.6/8.11.6) with ESMTP id g9L2fDU00318 for ; Mon, 21 Oct 2002 04:41:13 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sun, 20 Oct 2002 22:31:59 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sun, 20 Oct 2002 22:31:58 -0400 Received: from rwcrmhc51.attbi.com ([204.127.198.38]:32964 "EHLO rwcrmhc51.attbi.com") by vger.kernel.org with ESMTP id ; Sun, 20 Oct 2002 22:31:55 -0400 Received: from attbi.com ([24.60.61.209]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021021023755.DGMB18217.rwcrmhc51.attbi.com@attbi.com>; Mon, 21 Oct 2002 02:37:55 +0000 Message-Id: <3DB36877.9EFF8AA4@attbi.com> Date: Sun, 20 Oct 2002 22:37:43 -0400 From: Jim Houston Reply-To: jim.houston@attbi.com X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.17 i686) X-Accept-Language: en Mime-Version: 1.0 To: Rik van Riel Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, andrea@suse.de, jim.houston@ccur.com Subject: Re: [PATCH] Re: Pathological case identified from contest References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org Rik van Riel wrote: > > On Sat, 19 Oct 2002, Jim Houston wrote: > > + if (HZ > 100) > > + return(((p)->prio - MAX_RT_PRIO)*4 + 1); > > + else > > + return(((p)->prio - MAX_RT_PRIO)/2 + 1); > > } > > It'd be fun if this code also worked for values of HZ not > equal to 100 or 1000. Better put HZ somewhere in this > calculation and make it HZ-independant. Yes I will clean this up. > > + * The rq->prio_ind is used to raise/rotate the priority of all of the > > + * processes in the run queue. I know this sounds like a pyramid scheme. > > + * This increase in priority is balanced by two feedback mechanisms. > > + * First processes which consume there timeslice are moved to a lower > > + * priority queue. To continue the pyramid analogy we make the time > > + * slice smaller for more favorable priorities. > > Sounds like a good strategy, at least in theory. I suspect > it'll balance itself well enough to also work in practice. > > > + * The rotate_rate is the rate at which the priorities of processes > > + * in the run queue increase. With the initial HZ/10 guess a process > > + * will go from the worst dynamic priority to the best in 4 seconds. > > How long does it take for a best priority process to go > down ? I don't know yet. My next step will be to instrument this. There are a many things that I can be tuned here, but I want the system to tune itself. For example, I might measure the interval at which the lowest priority process gets to run and use this to adjust the rotate_rate. > > Or, for how much time can a newly started CPU hog starve > an older process ? This is important to know since eg. > a newly started Mozilla could starve an already running > movie player. The patch starts new processes with a neutral priority of 120. If it is a cpu hog, it will get one time slice at each priority until it reaches the priority where the existing group of cpu hogs are executing. At this point it will round robin with this group. The scheduler has no way to know which processes are interactive. In your example the user might be waiting for the Mozilla to start and not care if the movie player skips.  Jim Houston - Concurrent Computer Corp. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/