the reason idle-loop zeroing was disabled with the UBC merge was
that the current implementation caused a 50% performance penalty
for sequential reads, so it was turned off until it can be changed
to not trigger that.  it wasn't because of earlier reuse of pages,
but rather because the uncached accesses interfere with DMA (or
at least that's the theory).

there were a couple other minor optimizations that were disabled
in favor of UBC integration as well, one to do with NFS directory caching
and I think one other that I can't remember right now.  I'll be looking at
what it takes to re-enable all of these, or other people can work on them
if I take too long and people get impatient.  :-)

-Chuck


On Mon, Nov 27, 2000 at 06:32:10PM +0100, Sean Doran wrote:
> 
> I know that the apparent 1.5L change makes sense that
> page_idle_zero and UBC seem to be mutually exclusive --
> it's self-defeating to have usable buffer cache pages to
> be zorched just because the machine is idle -- but would
> it be reasonable to have a target of a few % of all pages
> sitting zero so that if something (fs i/o or whatnot)
> wants a burst of zero-filled pages the zero-fill penalty
> has been at least partially prepaid during idle moments?
> 
> It seems that the worst case would be that one zeros a
> page containing file-system data that one re-reads during
> the next burst of system activity, so perhaps this means
> "fine-tuning required".
> 
> (Come to think of it, should "fs read faults" eat spare
> zero-filled pages if we are below a threshold, or should
> those pages be set aside for more CPU-driven activities
> which need fresh pages?)
> 
>         Sean.