Re: [PATCH] 2.6.4-rc2-mm1: vm-split-active-lists

[Bill Davidsen]

Nick Piggin wrote:
> Matthias Urlichs wrote:
>
> > Hi, Andrew Morton wrote:
> >
> >
> > > That effect is to cause the whole world to be swapped out when people
> > > return to their machines in the morning.
> >
> > The correct solution to this problem is "suspend-to-disk" --
> > if the machine isn't doing anything anyway, TURN IT OFF.
>
> Without arguing that point, the VM also should have a solution
> to the problem where people don't turn it off.
>
> > One slightly more practical solution from the "you-now-who gets angry
> > mails" POV anyway, would be to tie the reduced-rate scanning to the load
> > average -- if nothing at all happens, swap-out doesn't need to happen
> > either.
>
> Well if nothing at all happens we don't swap out, but when something
> is happening, desktop users don't want any of their programs to be
> swapped out no matter how long they have been sitting idle. They don't
> want to wait 10 seconds to page something in even if it means they're
> waiting an extra 10 minutes throughout the day for their kernel greps
> and diffs to finish.

I have noticed that 2.6 seems to clear memory (any version I've run for 
a while) and a lunch break results in a burst of disk activity before 
the screen saver even gets in to unlock the screen. I know this box has 
no cron activity during the day, so the pages were not forced out.

It's a good thing IMHO to write dirty pages to swap so the space can be 
reclaimed if needed, but shouldn't the page be marked as clean and left 
in memory for use without swap-in nif it's needed? I see this on backup 
servers, and a machine with 3GB of free memory, no mail, no cron and no 
app running isn't getting much memory pressure ;-)

I am not saying the behaviour is wrong, I just fail to see why the last 
application run isn't still in memory an hour later, absent memory pressure.

--
		-bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/