Having the working set of one process larger than RAM is
a highly unusual case ...
> The page replacement algorithm ought to do something sane with it,
... page replacement ought to give this process less RAM
because it isn't going to get enough to run anyway. No need
to have a process like qsbench make other processes run
slow, too.
> and swap performance ought to be decent in general, since desktop users
> typically have less than 1/2 GB. With media apps, bloated desktops and
> all, it doesn't go as far as it used to.
The difference there is that desktops don't have a working
set larger than RAM. They've got a few (dozen?) of processes,
each of which has a working set that easily fits in ram and
a bunch of pages, or whole processes, which aren't currently
in use.
In this situation the VM _can_ keep the whole working set in
RAM, simply by evicting the stuff that's not in the working
set.
> My impression is that page replacement just hasn't gotten a lot of
> attention recently, and there is nothing wrong with that. It's tuning,
> not a feature.
As you write above, it's a pretty damn important feature,
though. One thing I'm experimenting with now for 2.4 rmap
is to ignore the referenced bit and page age if a page is
only in use by processes which haven't run recently, this
should help the desktop (and university) workloads by
swapping out memory from tasks which don't need it anyway
at the moment.
There may be other modifications needed, too...
regards,
Rik
-- A: No. Q: Should I include quotations after my reply?http://www.surriel.com/ http://distro.conectiva.com/
- 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/