[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: priority of ksysguard
From:       "Manuel Amador (Rudd-O)" <amadorm () usm ! edu ! ec>
Date:       2003-02-27 21:03:32
[Download RAW message or body]

Wait.  Several flaws with the design of the solutions:

Doesn't ksysguard operate by remote-controlling a daemon ksysguardd? 
 Then the *daemon* should have the higher priority.
Doesn't X run with normal or slightly higher but not max priority?

Even if you get ksysguard or its daemon to max priority, in this 
particular scenario you won't be able to kill the process smoothly, like 
you do in Windows.  Here's why:

what you had with your camera prob was not that the CPU got maxed, but 
rather that the hard disk thrashed because of lack of RAM: memory 
starvation.  The disk is maxed out so opening another app calls for 
pages in the virtual memory, but remember that the disk is maxed out. 
 Thus opening ksysguard aggravates the problem: it might open but REALLY 
slowly, and the disk operations are maxing the CPU itself, in desperate 
search for free memory (RAM or virtual).  Thus you never get to see a 
ksysguard (or rather after a couple of minutes).  When you see it, the 
thrashing has got control of your machine, and interactive response is 
extremely bad.  Then you kill the process and after like seems 15 
minutes your OS can breathe.

This is an issue in Linux 2.4, of course.  I hear that the speeculative 
scheduler helps in memory starvation and disk bandwidth starvation 
situations.  It might do wonders.  If this is true, the higher priority 
won't be needed at all.  Why?

The elevator algorithm in Linux for priorizing tasks penalize tasks that 
are consuming too much CPU, *without regard* to priority.  So you might 
have a process with nice -20, maxing the CPU, and you still should be 
able to open ksysguard and kill it.  That is, assuming it's not I/O 
bound or the machine isn't memory starved.

All other unices should be well.  I remember clearly that Linux 2.2 
offered much better interactive response in memory starvation 
situations.  What happened to that?  Dunno, but let's hope that the 
latest and greatest scheduler and disk algorithms get into mainline so 
we can enjoy that interactive response now.  And them patches evidently 
will improve multimedia response too, lowering minimum latency.

luck,

       Manuel

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]