Messages in this thread |  | | Subject | Re: 2.2.6_andrea2.bz2 | | From | (Eric W. Biederman) | | Date | 26 Apr 1999 03:05:56 -0500 |
| |
>>>>> "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).
The real gain of this is not so much in the current cases we are fast at but for things like network, and compressed files (in general anything that can't use the buffer cache). When someone has to roll their own caching mechanism from scratch it's usually much less efficient than the buffer cache, and much buggier.
Plus we gain efficiency for fsync since we don't have to walk all of the blocks in a file to see which ones are dirty, and for many read write operations on the same file blocks, because we won't be caching the data in memory twice, and being able to cache twice as much data will be a major performance gain.
I'd share my patches now, but I have one that I can't successfully boot with yet. The last bug I removed was a compiler bug in gcc-2.8.1. (unconfirmed)
Before I finalize the design I'll definentily look at what you have been doing with the buffer cache.
Currently I have a patch that keeps a list of dirty pages (and associated write times), and flushes them when needed or when the pages have been in the buffer long enough. Roughly modeled after the buffer cache. But it hasn't been tuned very much yet. The last working version didn't major performance problems though.
Once my current stuff starts working I should be able to start the research part of collapsing/removing unneeded layers from the system, which also should give a simplicity and performance boost. It currently looks like it may be possible to remove both the buffer cache and the operations from the vm_area struct. But only time will tell.
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/
|  |