[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.035 / U:3.104 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site