Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 6 Mar 2003 17:45:24 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 6 Mar 2003 17:45:24 -0500 Received: from svr-ganmtc-appserv-mgmt.ncf.coxexpress.com ([24.136.46.5]:14084 "EHLO svr-ganmtc-appserv-mgmt.ncf.coxexpress.com") by vger.kernel.org with ESMTP id ; Thu, 6 Mar 2003 17:45:23 -0500 Subject: Re: [patch] "HT scheduler", sched-2.5.63-B3 From: Robert Love To: Martin Waitz Cc: Linus Torvalds , Andrew Morton , mingo@elte.hu, linux-kernel@vger.kernel.org In-Reply-To: <20030306223518.GB1326@admingilde.org> References: <20030228202555.4391bf87.akpm@digeo.com> <20030306220307.GA1326@admingilde.org> <1046988457.715.37.camel@phantasy.awol.org> <20030306223518.GB1326@admingilde.org> Content-Type: text/plain Organization: Message-Id: <1046991366.715.52.camel@phantasy.awol.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-3) Date: 06 Mar 2003 17:56:06 -0500 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1844 Lines: 47 On Thu, 2003-03-06 at 17:35, Martin Waitz wrote: > processes tend to max out at one extreme or the other > > processes that get stalled by a huge overall load of the machine > are forced to sleep, too; yet they are not interactive. Not running != Sleeping > priority should be based on things the processes did, not on what > they haven't done. It _is_ based on something the process has done: sleeping in the kernel > but for interactive tasks, latency is all-important > if the task can't provide a result in a short timeslice it already > failed to provide low latency and should not be considered interactive > any more. Ahh, but you are confusing timeslice with the time a process runs for. This is what I pointed out in my initial email was your flaw :) A process may have a 100ms timeslice, but only run for 1ms at a time (100x before recalculating its quanta). This is the intention of giving large timeslices to interactive tasks: not that they need all 100ms at _once_ but they may need some of it soon, and when they need it they really NEED it, so make sure they have enough timeslice such that there is plenty available when they wake up (since the latency is important, as you said). > but the time slice should not be large enough to stall other > processes, which is extremely important for interactivity Once a process stalls other processes (i.e. by running a long time i.e. by being a CPU hog) then it loses its interactive bonus. The heuristic works. No one doubts that, modulo the corner cases we are working on fixing. I suggest you read the code. Robert Love - 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/