Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261687AbVECUqF (ORCPT ); Tue, 3 May 2005 16:46:05 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261690AbVECUqF (ORCPT ); Tue, 3 May 2005 16:46:05 -0400 Received: from viper.oldcity.dca.net ([216.158.38.4]:12961 "HELO viper.oldcity.dca.net") by vger.kernel.org with SMTP id S261687AbVECUp7 (ORCPT ); Tue, 3 May 2005 16:45:59 -0400 Subject: Re: question about contest benchmark From: Lee Revell To: Valdis.Kletnieks@vt.edu Cc: Haoqiang Zheng , linux-kernel@vger.kernel.org In-Reply-To: <200505032009.j43K9qQJ023179@turing-police.cc.vt.edu> References: <1115144999.29445.7.camel@mindpipe> <200505032009.j43K9qQJ023179@turing-police.cc.vt.edu> Content-Type: text/plain Date: Tue, 03 May 2005 16:45:57 -0400 Message-Id: <1115153157.29619.33.camel@mindpipe> Mime-Version: 1.0 X-Mailer: Evolution 2.3.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1562 Lines: 33 On Tue, 2005-05-03 at 16:09 -0400, Valdis.Kletnieks@vt.edu wrote: > On Tue, 03 May 2005 14:29:59 EDT, Lee Revell said: > > > But, it seems to me that even if an interactive process briefly goes CPU > > bound (due to bloat, bugs, or intent), it should still be scheduled > > preferentially to a pure CPU bound process like a build. > > So you want it to schedule that big image (Evolution) that's already used 5 > minutes of CPU since it started (this morning, admittedly) in preference to > that cc1 process that will be gone before it's used 2 seconds of CPU, plus all > the disk I/O that cc1 performs (hopefully the cache will help here, but it may > indeed go to disk to read the source files)? > Yes. Almost no one will notice whether that build took 2 or 4 seconds. But a few seconds is an eternity when you are staring at a blank pane, waiting for it to render the message list. And I found that when waiting for the message list to render, backgrounding the build causes it to render in a second or two, while if I just wait for it it might take 20 seconds. This implies that the scheduler could do the same thing. Anyway, this was not a great example, as the problem turned out to be an application bug. If I can find a non-pathological case that demonstrates a scheduler problem, I'll post it. Lee - 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/