Agreed. But this is meta data, not file data. Meta data should be
preferred to stay in the buffer cache over sequential file data. Plus,
when using du and find, you are referencing ONLY meta data, and apparently
that all fits into memory on your machine. The case that is problematic is
when reading lots of file data causes the buffer cache to overflow.
>Forcing executables in memory could also be a bad idea, since large
>parts of code would conceivably be executed only once, and there would
>be no benefit in sticking to them.
I agree, especially with code bloated apps these daze.
>I have a suspicion that memory which is referenced twice is much more
>likely to be referenced more in the future, while memory which has been
>referenced only once, in many cases won't be referenced again. This
>could hold for (parts of) executables, as well as data.
>
>Even if this holds true (which is, of course, purely conjecture), I've
>no idea whether/how it could be utilized in the VM system.
I'm not familiar with things yet, but was looking at dcache.c. It
implements a 2-level cache for directory entries. A similar strategy for
the buffer cache would seem to go a long way towards distinguishing between
buffers that may be useful in the cache versus file data that was
referenced once but isn't likely to be used again, and should be discarded.
The buffer cache would continue to grow to use all free memory, up to the
minimum free memory mark. Data from disk goes to the first level cache,
buffers that are fetched from the 1st level cache are promoted to the 2nd
level cache, LRU is done on both as in dcache.c. When no free memory is
available to expand the cache, least-recently-used buffers in level one are
reused. As buffers are promoted to level 2, the size of the level 1 cache
decreases. If the level 1 cache size gets "too small", and there is no
free memory, then it would be time to either start stealing application
code/data pages, or figure out if the least-recently-used level 2 buffers
are no longer useful. Of course, making that "no longer useful" decision
and setting the cache size limits is the fun part. :-)
Jim
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu