lkml.org 
[lkml]   [2003]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] O13int for interactivity
Con Kolivas wrote:

>Quoting Nick Piggin <piggin@cyberone.com.au>:
>

snip

>
>>Oh, I'm not saying that your change is outright wrong, on the contrary I'd
>>say you have a better feel for what is needed than I do, but if you are
>>finding
>>that the uninterruptible sleep case needs some tweaking then the same tweak
>>should be applied to all sleep cases. If there really is a difference,
>>then its
>>just a fluke that the sleep paths in question use the type of sleep you are
>>testing for, and nothing more profound than that.
>>
>
>Ah I see. It was from my observations of the behaviour of tasks in D that
>found it was the period spent in D that was leading to unfairness. The same
>tweak can't be applied to the rest of the sleeps because that inactivates
>everything. So it is a fluke that the thing I'm trying to penalise is what
>tasks in uninterruptible sleep do, but it is by backward observation of D
>tasks, not random chance.
>

Yes yes, but we come to the same conclusion no matter why you have decided
to make the change ;) namely that you're only papering over a flaw in the
scheduler!

What happens in the same sort of workload that is using interruptible
sleeps?
Say the same make -j NFS mounted interrruptible (I think?).

I didn't really understand your answer a few emails ago... please just
reiterate: if the problem is that processes sleeping too long on IO get
too high a priority, then give all processes the same boost after they
have slept for half a second?

Also, why is this a problem exactly? Is there a difference between a
process that would be a CPU hog but for its limited disk bandwidth, and
a process that isn't a CPU hog? Disk IO aside, they are exactly the same
thing to the CPU scheduler, aren't they?

_wants_ to be a CPU hog, but can't due to disk

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.158 / U:11.112 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site