Hmm, that's interesting. I wonder whether it should be investigated and fixed. there. :) On Tue, Jul 24, 2007 at 02:36:18PM -0500, Mike McCarty wrote: > Hugo Vanwoerkom wrote: >> http://apcmag.com/6735/interview_con_kolivas > [...] > > momentary freezes of the display (5-10 seconds) > lots of ghosting of moving mouse pointers and windows > momentary freezing of the keyboard (up to 30 seconds) > difficulty switching "workspaces" using GNOME (minutes delay) > very extended load times for apps (minutes to load acrobat, e.g.) > > This is on a 2.7 GHz machine with 250Meg of memory. Some of this > is explainable as memory thrashing, as evidenced by disc activity, > and memory pressure reported by top and similar tools. > > But, why is my disc running when I try to move my mouse? I completely agree. And it kills me. I have to wonder where all this overhead comes from. Obviously, in the case of running a cpu-intensive long-term job, its the scheduler. But what about the cases where this job isn't around? > > It took my machine 3 seconds to do a "copy" after selecting > that text on my screen, because the disc ran that long after > I clicked on the "Edit" button on the window frame. It had to hit > disc to load the image and/or software needed to copy the selected > text. I am running Thunderbird, one instance of Netscape, one instance > of acroread 7.0, and four xterm windows. > this is a perfect example. We shouldn't have to wait for stuff like this. What is the point of all this hardware? Obivously some of it is wasted cycles doing fun stuff like animating the window frame. But really, even with all this stuff turned off, there are serious flaws in performance for a desktop system. What is the model for responsiveness in the desktop system? Windows uses this model (when booting) where it looks like the system is ready even though its not. I guess that's supposed to make the user happier that the system booted up faster, but that's seriously flawed. In linux, we see less obfuscation of the fact that the machine is not yet ready to receive input from the user. THat's good. But then we have all these examples where the computer is doing stuff that is likely of no immediate consequence to the user and yet it is interrupting the flow of work by freezing the interface and other nastiness. IMO, a desktop system should behave in the following simple ways: 1. it should prioritise response to the user interface above all other things. 2. it should make some reasonable effort to inform the user about the state of completion of whatever tasks the user has invoked. 3. it should make some reasonable effort to notify the user _before_ the user enters a situation where the response to 1. is being impaired, though that should never happen because 1. is a priority. I don't know much about these things, but would love to discuss them. an example would be for 2, above: a spinning whirlygig is useless. I would rather see a progress bar or some other indicator that shows actual progress. Then I know how long I can spend on other things. i can reasonably estimate that I have time to read so many paragraphs before the progress bar completes. even better, some kind of OSD notifying me that such-and-such task in workspace 4 is ready to go... note that i don't mean a big pop-up window here... maybe the progress bar belongs in the systray or something like that... non-priority tasks need to really be non-priority. A run of updatedb is so ridiculously unimportant (that's why it runsin the middle of the night, I guess) that it should _never_ hinder user progress unless the user has specifically asked for the db to be updated because of some immediate need. Then it becomes a user task and recieves priority. But otherwise, it just doesn't matter. Does it really matter whether the update takes 3 minutes or 30? no. and if there is user activity going on, then the update just has to wait. period. there is so much downtime on a desktop system where the machine is just waiting, that I should _never_ have to wait for it to respond to me. Now maybe it can't get to yet-another-in-a-long-line-of-click-happy-user-tasks at just this moment, but it should remain responsive and tell me what's going on, not just sit there grinding away. I see this as more of a problem with less savvy users. A savvy user understands that there are limitations to what the computer can do (even if they don't know why) and have become trained to wait for the machine. But new, rookie, users don't understand why its not responding and frankly shouldn't have to. I watch my wife (not completely un-savvy) and kids react to a non-reactive interface: they click more... and more... because its not reacting, so it must not have heard them the first time. This makes the problem worse and worse as they layer on more and more required responses to a system that isn't allocating time to user responses. If the machine actually responded to each input in a clear and immediate way, the user wouldn't react by clicking more... I realise this means a complete restructuring of the desktop OS from the ground up. All apps have to report their progress; all processes have to be able to clearly express their priority based on context; the kernel has to be able to balance priorities in a way that maintains interfaces responsiveness above all. Probably swap behavior is important in all this, as well. I shouldn't be sitting at my desktop with 227 megs free and 248 megs in swap. (of course i've got 13 days uptime on still memory-leaking xfce, but that's a different matter). All user processes, to the extent possible should be in live memory. Why? because their my processes and when I want them, I want them now. So what if cron-apt has to work out of swap? who cares? I won't deal with cron-apt until its done and sent its email anyway, so its completion time is immaterial. I'm really rambling now. sorry. but i guess, now that I think of these things, I can really see where Con is coming from... A
Attachment:
signature.asc
Description: Digital signature