[lkml]   [1999]   [Nov]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux Buffer Cache & Mirroring


Thanks for the help. We are using ll_rw_blk with our own buffers heads,
similiar to what's in the XFS and other FS's. Things are working very
well. Performance on 2.2/2.3 has increased by several orders of
magnitude since we now have our tried and true async interface
(re-mirroring really needs async since it is so IO intensive). We are
seeing some issues getting the two cache's to co-exist regarding memory
sharing -- it seems that neither LRU wants to be friendly. We can
optimize to give back memory when we see low water/high water marks, but
the other buffer cache does not appear to do this. We may have to limit
how much memory we take. Also, Netware file systems expect three
separate global LRUs for their volumes, FAT, Directory, and Data.
Policies are different for each. Our LRU is a single code base that
allows different caching policies LRU "personalities" based on what is
expected. The design uses a handicap to force FAT and DIR buffers to
recycle through befoe being aged (FAT blocks must cycle through three
times before getting thrown out, though they always write-through,
whereas directory blocks cycle through twice. Data blocks once, etc.).
This LRU also handles the distributed cache semantics.

One thing you should warn folks about is that they need to call kmalloc
with the GFP_BUFFER priority for both the data buffers and the buffer
heads so the memory gets mapped logical=physical. Oddly, we did see
some problems with DMA timeouts if the buffer head was not also alloc'd
with GFP_BUFFER priority.

Thanks very much for the help.


Gerard Roudier wrote:
> On Wed, 3 Nov 1999, Stephen C. Tweedie wrote:
> > If the worst comes to the worst, you can just copy those functions in
> > your own module for 2.2 and ask for them to be exported symbols in 2.3.
> > The ll_rw_block API just wants something that looks like a buffer_head,
> > and doesn't care what code was called to create that structure.
> In my opinion, ll_rw_blk is something that may well disappear in 2.5/2.6.
> Exporting to much interfaces that refers to this layer may well add some
> legacies that will make things still harder for the change.
> In my experience, exportation of symbols is something that must be
> carefully controlled, otherwise we may end up with some montruous software
> that might get pretty impossible to evolve in the future.
> About callbacks, they are good when there are not to much abused. They can
> cause increase of interrupt latency and kind of wierd problems when not
> carefully understood and used. When, for example, we only need a thread
> to be waken up, some less general but less permissive mechanism should be
> preferred, in my opinion.
> Gérard.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to
> Please read the FAQ at

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:54    [W:0.082 / U:1.012 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site