Bart Smaalders <bart.smaalders at Sun.COM> wrote:
> Marion Hakanson wrote:
> > ervacon at gmail.com said:
> >> When the system is largly idle the gnome desktop feels fast and snappy, and
> >> interaction is very immediate. However, when I start a heavy background
> >> process (for instance a maven build of a large Java application), CPU
> >> utilization shoots to 100% on both CPU cores (which is good!), but my whole
> >> desktop becomes sluggish, even mouse movement becomes erratic.
> >
> > It's not necessarily CPU contention that's making things slow. My systems
> > behave this way when RAM is short; Xorg or window-manager get paged out,
> > and things get jerky/erratic.
>
> Our original prototype for the IA class back in the early 90s (!) did
> influence memory allocation, but this wasn't really tenable in a
> scheduling class. It did work very well, however.
>
> http://www.usenix.org/publications/library/proceedings/cinci93/full_papers/evans.txt
I am not sure whether this is a result of different usage or whether the current
implementation is worse than it was in the early 1990s when introducing the IA
class.
The main problem I currently see on Solaris is that paging on a loaded system
that uses more VM than real memory is available. It seems that the VM subsystem
pages out single pages altough it was much faster to page out larger chunks of
pages at a time.
If I have a system that is heavily paging and I call e.g.
sdd -inull bs=200m of=/dev/null count=1
to force 200 MB of memory to be paged out in a short time, the system behaves
more user friendly for some time after this.
Maybe it helps to introduce some kind of big enough hysteresis in the behavior
of the pageout kernel thread.
Note that because this behavior also applies to tmpfs and because some
applications store temporary data for CD/DVD creation in /tmp, there is a
big chance to get a buffer underrun while writing a CD/DVD media that is bigger
than the free RAM space in the system.
Another issue: Xsun did use mmap() to allocate bigger parts of memory in the
X server. If big memory leaking program like netscape died in former times,
Xsun did shrink. Today, we have firefox that itself allocates less memory than
before but rather forxes X to allocate more memory and Xorg is malloc() based
and this does not shrink when fireforx dies.......
J?rg
--
EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin
js at cs.tu-berlin.de (uni)
joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
