Fastest System Possible

[Evan Klitzke]

On Mon, 2007-02-05 at 12:12 -0800, Bill Watson wrote:
> The applications run a distributor wall to wall. The application
> language is UniBasic by Dynamic Concepts, but that is probably
> meaningless to most/all. The application *used* to be diskbound, but
> with more memory than data in recent machines, I am not sure if that
> will still be an issue.
>  
> Any hints to cause 4.0 to leave all the disk in memory? Is this a good
> idea?

This is sort of a hack, but Linux allows you to create and mount
ramdisks. These are regions of memory that you allocate and tell the
kernel to treat like a disk device. So if you _really_ want things on
disk in memory, you can create a ramdisk, copy the files to the ramdisk,
and then tell the application that the data is located at wherever you
mounted the ramdisk.

I need to emphasize that this is really a hack. If you need to be able
to write data, then you will definitely need some mechanism that
synchronizes writes to the ramdisk with the contents on disk --
otherwise when the server loses power unexpectedly, all of the data that
was "written" will be lost. On the other hand, if you have some
read-only data this is probably a fine solution.

If the Basic system makes use of the mmap() call, this kind of thing may
actually be happening behind the scenes already, with the kernel
buffering disk reads and writes in memory. I think that the kernel is
capable of buffering some other kinds of kids reads and writes in memory
as well, so this may not even be an issue.

-- Evan Klitzke