Re: please revert bogus patch to vmscan.c

Benjamin LaHaise
2001-10-30T16:33:55Z

On Tue, Oct 30, 2001 at 04:51:19PM +0100, Andrea Arcangeli wrote:
> Anwyays this have _nothing_ to do at the very least with stability
> unlike the above subliminal messages are implying, see above, it can
> only potentially be less responsive under very heavy swap on ia64 and
> ppc (dunno sparc64?), period. mentioning real life workloads like Oracle
> and RHDB in relation to the tlb flush for the accessed bit is further
> subliminal bullshit, Oracle definitely isn't supposed to swap heavily
> during the benchmarks, and I'm sure it's not the case for mainline
> postrgres either (dunno about RHDB).

It has nothing to do with subliminal effects, but rather what kind of
effect this microoptimization is going to have in the Big Picture. What
I'm contending is that the Real World difference between the correct
version of the optimization will have no significant performance effects
compared to the incorrect version that you and davem are so gleefully
advocating. This means not running through "bullshit" benchmarks that
test one and only one thing, but running apps that actually put memory
pressure on the system (Oracle does so quite nicely using a filesystem
without O_DIRECT) which in turn causes page scanning (aka the clearing
of the referenced bit which is *THE* code that is being contested) but
should not cause swap out. To me, this is just part of the methodology
of being thorough in testing the effects of changes to the VM subsystem.

Frankly, I'm suitable unimpressed with the thoroughness of consideration
and testing to the changes currently being pushed into the base tree.
Again, this is why I'm not bothering to run base kernels.

-ben
--
Fish.