Messages in this thread | | | Date | Tue, 05 Aug 2003 15:28:22 +1000 | From | Nick Piggin <> | Subject | Re: [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/
| |