Re: (reiserfs) Re: More on Re: (reiserfs) Reiserfs and ext2fs (was Re: (reiserfs) Sum Benchmarks (these look typical?))

quoted

quoted

quoted

quoted

"ST" == Stephen C Tweedie [off-list ref] writes:

ST> Hi,
ST> In article [off-list ref], ebiederm+eric@npwt.net (Eric
ST> W. Biederman) writes:

quoted

Unless I have missed something write-back from the page cache is
important, because then when you delete a file you haven't written yet
you can completely avoid I/O.   For short lived files this should be a
performance win.

ST> We already do bforget() to deal with this in the buffer cache.  Having
ST> the outstanding IO labelled in the buffer cache will not result in
ST> redundant writes in this case.

That's good to know. It doesn't suprise me but I hadn't been through the
code enough to see that one.  I knew about bforget I just hadn't seen
it used.

quoted

quoted

quoted

This functionality is essentially what is implemented with brw_page,
and I have written the generic_page_write that does essentially
this.  There is no data copying however.  The fun angle is mapped
pages need to be unmapped (or at least read only mapped) for a write
to be successful.

ST> Indeed; however, it might be a reasonable compromise to do a copy out
ST> from the page cache to the buffer cache in this situation (we already
ST> have a copy in there, so this would not hurt performance relative to
ST> the current system).  

quoted

Agreed.  But it takes more work to write.

ST> On reflection, it's not an issue.  Mapped pages do not have to be
ST> unmapped at all.  We can continue to share between cache and buffers as
ST> long as we want.  Later modifications to the data in the cache page will
ST> update the buffer contents, true, but that's irrelevant as we will still
ST> be writing valid file contents to disk when the IO arrives.  Those
ST> semantics are just fine.

There are two problems I see.  

1) A DMA controller actively access the same memory the CPU is
accessing could be a problem.  Recall video flicker on old video
cards.

2) More importantly the cpu writes to the _cache_, and the DMA
controller reads from the RAM.  I don't see any consistency garnatees
there.  We may be able solve these problems on a per architecture or
device basis however. 

Eric

Hi,

On 29 Jun 1998 14:59:37 -0500, ebiederm+eric@npwt.net (Eric
W. Biederman) said:

There are two problems I see.  

1) A DMA controller actively access the same memory the CPU is
accessing could be a problem.  Recall video flicker on old video
cards.

Shouldn't be a problem.

2) More importantly the cpu writes to the _cache_, and the DMA
controller reads from the RAM.  I don't see any consistency garnatees
there.  We may be able solve these problems on a per architecture or
device basis however.

Again, not important.  If we ever modify a page which is already being
written out to a device, then we mark that page dirty.  On write, we
mark it clean (but locked) _before_ starting the IO, not after.  So, if
there is ever an overlap of a filesystem/mmap write with an IO to disk,
we will always schedule another IO later to clean the re-dirtied
buffers.

--Stephen