Re: please revert bogus patch to vmscan.c

[Benjamin LaHaise <bcrl@redhat.com>]

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.