Re: [PATCH] O13int for interactivity

[Nick Piggin <piggin@cyberone.com.au>]

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