>>> 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/