[lkml]   [2003]   [Aug]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] O13int for interactivity
On Tue, 5 Aug 2003 15:28, Nick Piggin wrote:
> Con Kolivas wrote:
> >Quoting Nick Piggin <>:
> 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!

This would take a redesign in the interactivity estimator. I worked on one for
a while but decided it best to stick to one infrastructure and tune it as
much as possible; especially in this stage of 2.6 blah blah...

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

Dunno. Can't say. I've only ever seen NFS D but I don't have enough test

> 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

You're on the right track; I'll try and explain differently.

A truly interactive task has periods of sleeping irrespective of disk
activity. It is the time spent sleeping that the estimator uses to decide
"this task is interactive, improve it's dynamic priority by 5". A true cpu
hog (eg cc1) never sleeps intentionally and the estimator sees this as "I'm a
hog; drop my priority by 5". Now if the cpu hog sleeps while waiting on disk
i/o the estimator suddenly decides to elevate it's priority. If it gets to
maximum boost and then stops doing I/O and goes back to being a hog it now
starts starving other processes till it's dynamic priority drops enough
again. As I said it's a design quirk (bug?) and _limiting_ how high the
priority goes if the sleep is due to I/O would be ideal but I don't have a
simple way to tell that apart from knowing that the sleep was
UNINTERRUPTIBLE. This is not as bad as it sounds as for the most part it
still is counted as sleep except that it can't ever get maximum priority
boost to be a sustained starver.

However, since you're a disk I/O kind of guy you may have a better solution to
this problem and give me some data I can feedback into the estimator ;-)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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