Re: More info: 2.1.108 page cache performance on low memory

Eric W. Biederman
1998-08-20T14:30:47Z

>>>>> "ST" == Stephen C Tweedie <sct@redhat.com> writes:

ST> Hi,
ST> On Sun, 2 Aug 1998 00:19:52 -0500 (CDT), Eric W Biederman
ST> <eric@flinx.npwt.net> said:

>> What I was envisioning is using a single write-out daemon
>> instead of 2 (one for buffer cache, one for page cache). Using the same
>> tests in shrink_mmap. Reducing the size of a buffer_head by a lot because
>> consolidating the two would reduce the number of lists needed.
>> To sit the buffer cache upon a single pseudo inode, and keep it's current
>> hashing scheme.

ST> The only reason we currently have two daemons
But I have 3.
One for writing dirty data in the buffer cache. bdflush
One for writing dirty data in the page cache. pgflush
One for reclaiming clean memory kswapd

I would like to merge bdflush and pgflush in the long run if I can.
Since pgflush is more generic than bdflush it should be doable.
This happens to give a degree of page cache and buffer cache unification
as a side effect, of setting up the buffer cache to use pgflush.

ST> is that we need one for
ST> writing dirty memory and another for reclaiming clean memory. That way,
ST> even when we stall for disk writes, we are still able to reclaim free
ST> memory via shrink_mmap(). The kswapd daemon and the shrink_mmap() code
ST> already treat the page cache and buffer cache both the same.

I was talking of integrating my ``dirty data in the page cache'' code,
in with the rest of the kernel. Hopefully for early 2.3.

My apologies for being so unclear you totally missed what I was talking about.

Eric