Sorry, but that's not a situation I can live with.
I don't know how or why the kernel could ever become unstable just because
we try swapping out a few pages once in a while instead of waiting until
the buffer cache is effectively gone because RAM is full. All I know is
that the code as it is now thrashes the buffer cache as soon as you run
something like a Netnews server under conditions where 2.0.29 churned along
quite happily.
> ... it's trivial but if two processes have more than the half physical
> memory over the most time and the system performance needs ram ...
> it's a `Binsenweisheit'.
>
Not in my situation. squid doesn't really need half the RAM (the system has
96 MBytes), it runs quite well with an RSS of ten MBytes or so. Once I
reapplied my state code fix, those 40 MBytes actually got swapped out
instead of sitting there and doing nothing.
Ditto for INN, which now uses 10 Mbytes (and another 20 on swap) instead of
25 MBytes in core. News processing speed is up; the 150 MBytes of
compressed newsbatches I've accumulated with the old code during the last
few days are down to 100 MBytes.
I spent the last half hour playing around with swapctl parameters and did
manage to get the Netnews article processing speed almost back to 2.0.29
levels. Without my state fix, the thing refused to do more than a third of
that, and swapctl changes didn't have any effect at all (not surprisingly,
since the machine wasn't swapping).
Right now vmstat shows 10 swap and 50 block I/O operations per second with
vmstat and runs reasonably well. Before applying my patch, it was zero
swap, 80 block, and the thing was slow like molasses.
The system is still not fast enough for my taste, but I can live with it
until the real problem is found; 2.0.29 would have eaten those 150 MBytes
during lunch break (OK, OK, almost...).
NB: I'm only talking about article processing speed here. Interactive
response time doesn't change much one way or the other.
-- Matthias Urlichs