Thomas Wagner wrote:
Eric Saxe wrote:
Ian Murdock wrote:
Desktop responsiveness could use some work. There was a lot of
work done in the Linux kernel a few years ago to improve this on
Linux, and it made a world of difference there.. I computed an
md5sum last night on an ISO image, which degraded desktop
responsiveness pretty badly. And while audio works beautifully compared
to Linux in how it multiplexes multiple streams, it's pretty jittery
>from time to time, presumably due to scheduler prioritization
(not prioritizing interactive tasks ahead of non-interactive tasks).
The timeshare scheduling class should be doing the right thing here. The
more CPU bound md5sum should tend to have it's priority drop, while the
more transient interactive tasks should have their priorities increase.
I use "mpd" (Music Play Daemon) and put this one in the RT (RealTime)
class. All Problems with playing back mp3s witch high sysload went away.
The same great results when playing videos with "mplayer" in the RT
scheduling class.
(moving this branch of the thread over to the perf-discuss list)
So a word of caution...things in the RT scheduling class can preempt
nearly everything (including the
kernel). So on a single CPU system, if your application (running in the
RT scheduling class) were to want as
much CPU as it could get, it would likely get what it wants, leaving
little to no CPU time for anything
else. :) So it's probably good to be a bit careful here, making sure
that the application really is interactive (and not
purely CPU bound).
Thomas, where was the high system load coming from that was interfering
with mpd and mplayer?
Thanks,
-Eric
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
