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/
This archive was generated by hypermail 2b29 : Thu Aug 07 2003 - 22:00:27 EST