Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 4 Apr 2001 03:55:46 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 4 Apr 2001 03:55:36 -0400 Received: from chiara.elte.hu ([157.181.150.200]:26124 "HELO chiara.elte.hu") by vger.kernel.org with SMTP id ; Wed, 4 Apr 2001 03:55:28 -0400 Date: Wed, 4 Apr 2001 08:53:36 +0200 (CEST) From: Ingo Molnar Reply-To: To: Fabio Riccardi Cc: Mike Kravetz , , Linux Kernel List , Alan Cox , Linus Torvalds Subject: Re: a quest for a better scheduler In-Reply-To: <3ACA683A.89D24DED@chromium.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 3 Apr 2001, Fabio Riccardi wrote: > I've spent my afternoon running some benchmarks to see if MQ patches > would degrade performance in the "normal case". no doubt priority-queue can run almost as fast as the current scheduler. What i'm worried about is the restriction of the 'priority' of processes, it cannot depend on previous processes (and other 'current state') anymore. to so we have two separate issues: #1: priority-queue: has the fundamental goodness() design limitation. #2: per-CPU-runqueues: changes semantics, makes scheduler less effective due to nonglobal decisions. about #1: while right now the prev->mm rule appears to be a tiny issue (it might not affect performance significantly), but forbidding it by hardcoding the assumption into data structures is a limitation of *future* goodness() functions. Eg. with the possible emergence of CPU-level threading and other, new multiprocessing technologies, this could be a *big* mistake. the Linux scheduler is not designed for the case of 1000 runnable processes. Ingo - 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/