Messages in this thread | | | Subject | Re: 2.2.6_andrea2.bz2 | From | (Eric W. Biederman) | Date | 26 Apr 1999 09:20:33 -0500 |
| |
>>>>> "AK" == Andi Kleen <ak@muc.de> writes:
AK> On Mon, Apr 26, 1999 at 10:05:56AM +0200, Eric W. Biederman wrote: >> >>>>> "AA" == Andrea Arcangeli <andrea@e-mind.com> writes: >> >> >>> o update_shared_mappings (will greatly improve performances while >> >>> writing from many task to the same shared memory). >> >> >> >> do you have performance numbers on this? >> AA> The performance optimization can be huge. >> AA> The reason this my code is not in the kernel is not because it's buggy but AA> simple because there are plans for 2.3.x (no-way for 2.2.x) to allow the AA> file cache to be dirty (to cache also writes and not only read in the page AA> cache). >> >> Andrea. The plan (at least my plan) is not to have 2 layers of buffers. >> Instead it is to do all of the caching (except for perhaps superblocks, and their >> kin in the page cache). brw_page will be used for both reads and writes, with >> anonymouse buffer heads (at least for a start).
AK> Stupid question: do you plan to cache fs metadata in the page cache too? AK> If yes, it is rather wasteful to use a 4K page for the usually block sized AK> directories and other fs data like indirect blocks. How do you plan to AK> address this problem?
I certainly plan on investigating it. I currently have the buffer pointer in struct page, set up as a generic pointer. So you can either use it's bits directly to keep track of what is dirty on a page. Or you can allocate a structure to have such things as a per page list of dirty places (like nfs does now).
For the start however the buffer cache will remain for the fs metadata.
But the fs metadata should be small enough that even if cached a little inefficiently we shouldn't have space problems. At least that's my hunch.
Eric
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |