Re: [PATCH] O13int for interactivity

[Mike Galbraith <efault@gmx.de>]

At 08:11 AM 8/5/2003 +1000, Con Kolivas wrote:
>On Tue, 5 Aug 2003 06:11, Mike Galbraith wrote:
>
> > IMHO, absolute cut off is a very bad idea (btdt, and it _sucked rocks_).
> >
> > The last thing in the world you want to do is to remove differentiation
> > between tasks... try to classify them and make them all the same within
> > their class.  For grins, take away all remaining differentiation, and run a
> > hefty parallel make.
>
>I didn't fully understand you but I get your drift. I have a better solution
>in the works anyway but I wanted this tested.

WRT disk wait:  The pure disk load turns into a problem here only while 
it's writing heavily, which means to me that either write throttling needs 
a bit of work, or async write boost needs a bit of throttling (same 
thing).  To me, async operations using sync wakeups makes more sense than 
trying to discriminate based upon task state.  Writes are generally async, 
and reads are generally sync.  If a task is in D state waiting for a write 
request to become available, it doesn't seem to me to be a good idea to 
boost his priority, that allows the guy who is overloading your I/O system 
and beating up your pagecache to preempt other pagecache users as soon as a 
request becomes available.  OTOH, a reader is almost always (except for 
readahead?) sync, and _needs_ to be able to preempt to use the data it 
waited on.  Take for example swapin; remove the sleep credit for swapin, 
and watch the thrash-fest begin... the light to moderate swap load that 
your box formerly handled easily suddenly becomes a horrible mess.

         -Mike

[aside: "D state is involuntary sleep" is kinda wrong-minded I think.  The 
only voluntary sleep is a yield.  All others could just as well be 
considered involuntary (also wrong).  A good example of what I mean is the 
problem with X and xmms's gl thread inverting their priorities once X 
expires in the presence of a non-interactive load.  X isn't running at prio 
25 because it is inherently a cpu hog, and the gl thread isn't at prio 16 
because it's voluntarily sleeping.  The situation is exactly the 
opposite.  The gl thread is a huge cpu hog that is "involuntarily" 
sleeping, waiting on X, who is "involuntarily" permanently running because 
it can't get enough cpu to catch up with it's workload so it can do what it 
normally does, sleep.  Also as an aside, if you want to have lots of fun 
with D state, play with semaphores.  Test results of using async/sync 
wakeups there can be highly counter-intuitive.]