The biggest change is probably making the buffer cache a drop-in
module that you can enable or disable with a config switch at kernel
compile time. If your filesystem is running from non-volatile ram, why do
you need a buffer cache? Does the bus make a difference here (main memory
bus vs peripheral bus)? Such systems won't need swap, either, if it
is on a main memory bus (I've heard 20 ns latency on polymer/silicon
hybrid ram; it was 50ns six months ago; it will be cheaper to produce than
pure silicon ram and improves the bits per volume by orders of magnitude;
don't expect this to not be affordable).
As for the rest of it, a big logical ramdisk is probably the easiest
upgrade path (doesn't require changing anything in the filesystem
indexing code, that can just be done if it's advantageous to do so). I
wonder if we'll need a flag to mmap() to choose "modify in place" or
"copy-modify-msync", which means that the change to a file in the second
case isn't persistent until the msync().
Working apm code probably handles the persistent process image issues
initially, so there should be a fairly smooth upgrade path to leveraging
the convenience of cheap giga-ram.
This is simply a hint to not spend immense resources on more
intricate buffer cache schemes and seek-optimizing filesystem algorithms,
because in the not too distant future those will be non-issues for most
systems (network buffering, that's something different of course;
maybe a "don't buffer/do buffer" per filesystem granularity will be
useful).
Regards,
Clayton Weaver
<mailto:cgweav@eskimo.com>
(Seattle)
"Everybody's ignorant, just in different subjects." Will Rogers
-
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/