Subject: Re: question about contest benchmark
From: Lee Revell <rlrevell@joe-job.com>
To: Haoqiang Zheng <haoqiang@gmail.com>
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <d6e6e6dd05050311115d256213@mail.gmail.com>
References: <d6e6e6dd05050311115d256213@mail.gmail.com>
Content-Type: text/plain
Date: Tue, 03 May 2005 14:29:59 -0400
Message-Id: <1115144999.29445.7.camel@mindpipe>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1202
Lines: 27

On Tue, 2005-05-03 at 14:11 -0400, Haoqiang Zheng wrote:
>  My question is why is the result bad at all? One could certainly
> argue that contest processes shouldn't consume so much CPU time since
> they are considered to be background jobs. But why is kernel compiling
> considered foreground jobs? Why making kernel compiling faster is
> better?

I have reported the same problem before.  CPU bound processes like
kernel compiles will sometimes starve interactive processes like my mail
client (Evolution).

Actually, I discovered a horrible performance bug in Evolution
(suboptimal "hide junk" implementation, and searches for "" not properly
optimized away, see evolution-hackers for a rough patch) that was
responsible for the massive CPU suckage.

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.

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/