On Tue, 2005-05-03 at 16:09 -0400, [email protected] 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
