Re: [PATCHES]

["Stephen C. Tweedie" <sct@redhat.com>]

Hi,

On 23 May 1999 13:34:11 -0500, ebiederm+eric@ccr.net (Eric W. Biederman) said:

> My work on dirty pages sets up a bdflush like mechanism on top of the page
> cache.  So for anything that can fit in the page cache the buffer cache
> simply isn't needed.   Where the data goes when it is written simply doesn't
> matter.

One good reason for using buffers aliased into the page cache is
precisely to avoid a new bdflush mechanism.  We have had enough deadlock
and resource starvation issues with one bdflush that I get nervous about
adding another one!

(IM == Ingo)
IM> I'd like the page cache end up in a design where we can almost
IM> completely avoid any filesystem overhead for quickly
IM> created/destroyed and/or fully cached files. I'd like to have a very
IM> simple unaliased pagecache and no filesystem overhead, on big RAM
IM> boxes.  This was the orignal goal of the page cache as well, as far
IM> as i remember.

Actually the initial motivation of the page cache was to try to keep
per-file dirty lists, to fix fsync.  We just never got round to that!

However, this brings up another point: 

	ftp://ftp.uk.linux.org/pub/linux/sct/fs/misc/fsync-2.2.8-v5.diff

is a set of diffs to fix fsync performance on 2.2.  It fully implements
fsync and fdatasync, and applies the same optimisations to O_SYNC.  It
uses per-inode dirty buffer lists.  Please bear in mind that we still
need such functionality even with the dirty-page-cache mechanism, to
keep track of the indirect blocks if nothing else.

--Stephen

--
To unsubscribe, send a message with 'unsubscribe linux-mm my@address'
in the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/