> Here is the problem: Mozilla should not have been paged out if it was
> in active use. The UBC system doesn't understand the concept of
> "working set" or even an approximation, so it will readily gooble
> memory and cause Mozilla, X, and many other large processes to page
> out. I think that there needs to be a way to effectively prioritize
> pages in memory so better choices are made for replacement. When these
> applications eventually execute (like to update the display) and get
> paged back in, of course the effective memory access time gets
> thousands of times slower and which is why something that is not disk
> intensive (like screen repainting) takes longer.

I have a hunch that pages are recycled on a 'least recently used'
basis.  If a single page of your idle mozilla is paged out, then
when you restart it is odds-on that another page of mozilla
will be discarded in order to re-read the page you want.
So the entire working set gets cycled through when only
one page is absent.

I also suspect that increasing the number of pages brought
in for each page fault will help.  The default is 8 pages
(does this apply when all memory is in use? if single
pages are being brought in then that might account for the
delays).
Unfortunately my attempt to increase the numbers caused
a panic during boot - probably because 32k is the size of
the buffers used for metadata (etc).

Some sort of weighting for pages (cf process priorities)
that meant that pages that have been used many times are
less likely to be discarded than those only accessed once
might help.  Discarding random pages might even work!

After all if the system has N pages, but the working set
is N+n pages then you want to leave a lot of pages
permanently resident and rotate a small number of pages
through a few pages of physical memory.

	David

-- 
David Laight: david@l8s.co.uk