On Mon, 2003-06-23 at 12:50, John Bradford wrote:
> > Maybe I have different a different idea of what "interactive" should be.
>
> [snip]
>
> > moving windows around the screen do feel jerky and laggy at best
> > when the machine is loaded. For a normal desktop usage, I prefer all
> > my intensive tasks to start releasing more CPU cycles so moving a
> > window around the desktop feels completely smooth
>
> That's fine for a desktop box, but I wouldn't really want a heavily
> loaded server to have database queries starved just because somebody
> is scrolling through a log file, or moving windows about doing admin
> work.
I agree 100%... So this leads us to having two different set of
scheduler policies: for desktop usage, and for server usage. For desktop
usage, most of the apps need CPU bursts for a bried period of time. For
server usage, we want a more steady scheduling plan.
> If I was simply typing a letter, I wouldn't really care about
> interactivity. If I was using a heavily loaded server to do it,
> (unlikely), I'd rather the wordprocessor was starved, and updated the
> screen once per second, and gave more time to the server processes,
> because I don't need the visual feedback to carry on typing. Screen
> updates are a waste of CPU in that instance - it might look nice, but
> all it's doing is starving the CPU even more.
So, opaque window moving is also a waste of time and we'd better stick
to border-only (transparent) window moving ;-)
Nah! I also think it'a waste of time, but Joe-end-user won't think the
same. He'll have a better feeling using more CPU to refresh the screen
at a faster rate, even when that's a waste of CPU cycles. Look at
Windows or Mac with all those nice, CPU-wasting visual effects.
> I propose a radically different approach to scheduling, why not
> favour processes that cause the fewest cache faults? I.E. if a
> process that gets more done in it's timeslice is more deserving of
> it. It might look ugly with screen updates being starved, but it
> would probably get more work done :-).
What would happen with poorly written programs? There are a lot of them
that don't take advantage of memory locality, are not designed to fully
utilize the cache, or use arrays in a way that produces too much
page/cache faults.
-
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/
This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:40 EST