No it's not, it's very similar to having several processes active whose
working sets add up to more than RAM.
> > 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.
It should run the process as efficiently as possible, given that there
isn't any competition.
> > 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.
Try loading a high res photo in gimp and running any kind of interesting
script-fu on it. If it doesn't thrash, boot with half the memory and
repeat.
> 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.
We're not talking about that case. Oh, by the way, since when did
it become ok to ignore corner cases? I thought corner cases were what
users have been flaming us about for the last 2 or 3 years.
> > 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...
No doubt, and for the first time, we've got a solid base to build on.
-- Daniel - 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/