Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 6 Mar 2003 16:56:59 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 6 Mar 2003 16:56:59 -0500 Received: from svr-ganmtc-appserv-mgmt.ncf.coxexpress.com ([24.136.46.5]:42768 "EHLO svr-ganmtc-appserv-mgmt.ncf.coxexpress.com") by vger.kernel.org with ESMTP id ; Thu, 6 Mar 2003 16:56:57 -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: <20030306220307.GA1326@admingilde.org> References: <20030228202555.4391bf87.akpm@digeo.com> <20030306220307.GA1326@admingilde.org> Content-Type: text/plain Organization: Message-Id: <1046988457.715.37.camel@phantasy.awol.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.2 (1.2.2-3) Date: 06 Mar 2003 17:07:37 -0500 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1053 Lines: 27 On Thu, 2003-03-06 at 17:03, Martin Waitz wrote: > RE: the patch, i think using sleep_avg is a wrong metric from the > beginning. Eh? It is as close to a heuristic of interactivity as I can think of. > in addition, timeslices should be shortest for high priority processes > (depending on dynamic prio, not static) No, they should be longer. In some cases they should be nearly infinitely long (which is sort of what we do with the reinsertion into the active array for highly interactive tasks). We want interactive tasks to always be able to run. You may think they need shorter timeslice because they are I/O-bound. Keep in mind they need not _use_ all their timeslice in one go, and having a large timeslice ensures they have timeslice available when they wake up and need to run. 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/