On 11 Oct 1999 17:58:54 -0500, [EMAIL PROTECTED] (Eric W. Biederman) said:
> > Ultimately we really want to have indirect blocks, and the directory
> > in the page cache as it should result in more uniform code, and
> > faster partial truncates (as well as faster syncs).
Stephen C. Tweedie <[EMAIL PROTECTED]> wrote:
> There is one major potential future problem with moving this to the
> page cache. At some point I want to be able to extend the large (64G)
> memory support on Intel to include the page cache in high memory.
> The buffer cache would still live in low memory. If we do that, then
> moving filesystem metadata out of permanently-mapped buffer memory
> and into the page cache is going to complicate directory and indirect
> operations significantly.
Because of write ordering, I presume -- the dirty buffers you want most
likely want to be able to write are (of the dirty buffers) the ones you
most likely want to move out to large memory?
Is there a problem with the simple answer (don't move dirty buffers
there)? It seems like the only problem there would be memory pressure,
nothing algorithmic. If so, I'm guessing that the trick is how to best
save write order for dirty blocks in large memory?
Unless I'm way off base, the second simplest answer is don't move dirty
meta-data blocks out to large memory. That's going to cost you an if ()
-- and I suppose it may mean some extra L1 cache pressure for machines
with large memory support compiled in -- but otherwise doesn't seem any
worse than the current situation.
--
Raul
