Re: Working on the ddf

[Gianluca Guida]

At Thu, 15 Apr 2004 10:12:10 -0400,
Neal H. Walfield wrote:
> 
> > However, if you want low-level I/O caches
> > (gianluca thinks they are essential, but neal and me believe caching
> > is better done at higher levels, like the filesystem), then it makes
> > sense to treat cache memory specially (using extra pages).  So, some
> > considerations apply here, but in general, don't worry too much about
> > it.
> 
> This wasn't quite clear to me but what I think marcus is referring to
> with low-level I/O caches are block level caches (i.e. versus file
> system level caches).
> 

I assume he was talking about block level caches, and this is what 
I'll mean by 'caches' later on.

> A block level cache is going to be, at best, fairly stupid (it can
> detect some types of access patterns but does not have the benefit of
> knowing how files are laid out, etc. like the file system does).  As
> there will rarely be more than one user of a block level device (for
> obvious cache consistency reasons, e.g. one should never fsck a
> mounted file system), it seems that there is little to be gained by
> adding this extra level of less intelligent caching: it will only
> compete for physical memory with the file system cache.
> 

Smartness of the caches is an important issue of cache management, 
but it's not the only one. Comparing two caches of similar size, 
the smarter one could have a a lower cache miss rate.

I think the problem underestimating here is the size of caches. 
Managing block caches as normal process memory won't work too well. 
The mempolicy server should treat them as a special memory. 

In fact a reasonable and fair policy to handle common process memory is 
to give more pages to the process that is experiencing more page faults 
(of course we could have memquota to prevent DOS attacks).

This policy, however, is not good with I/O block data caches. Is pretty 
intuitive that we should enlarge this cache when there is not so much 
memory pressure (read: other process aren't having too much page faults
and we are not short on memory) but we are experiencing a lot of cache
misses in it; we should instead shrink a cache when the processes memory 
pressure (page fault rate) is high compared to the cache's miss rate.

What i want to say with this is that I/O block data caches can't be 
treated as normal memory implemented in an untrusted server. They are a 
separate and independent concept that should be taken into account when 
designing physical memory management of an Operating System. 

Gianluca