On Wed, Apr 04, 2001 at 08:37:50PM -0000, eeh@netbsd.org wrote:
>> 
>> That's also done by my patch.  (At least that's what I thought when I wrote
>> the patch.)  Pages are immediately cleaned and put onto the idle list.  Of
>> course this implementation could cause other performance problems, like 
>> multiple writes of the same page, and does chew up lot's of CPU time.
>
>Doesn't this also basically defeat the write-behind nature of the buffer
>cache and make all I/O if not synchronous, quite close to it?
> 
> Yes.
> 
> Does write-behind actually gain you anything other than give the system
> more time to coalesce writes?  It certainly is one of the main causes
> of the performance problem since all RAM can eventually contain dirty
> buffers that need to be flushed.

It gains a tremendous amount.  There's quite a bit of literature on why, but
the basic principle is pretty obvious: disks do not handle many small
transactions as well as few large transactions.  Furthermore, preserving the
asynchronous nature of many operations is key to maintaining a high tps for
the entire I/O subsystem.

When LFS is UBC-aware, the change you propose will also essentially make it
unworkable unless it copies to private buffers behind UBC's back (ideally,
LFS should simply produce 1MB of clean pages every time it does a segment
write).

I think the right way to address your concern -- though it's nontrivial --
is to teach the I/O subsystem to attempt to maintain a constant rate of
I/O.  Then we can flow-control the buffer cache so that we do not accept
writes we can't clear in some known amount of time (let them block).

This is similar to something LFS needs to do, actually.  What do you think?

Thor