lkml.org 
[lkml]   [1998]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: elevator algorithm bug in ll_rw_blk.c
    On Mon, 16 Nov 1998, Gerard Roudier wrote:

    > On Mon, 16 Nov 1998, Stephen C. Tweedie wrote:

    > > On Sun, 15 Nov 1998 20:38:05 +0100 (MET), Gerard Roudier
    > > <groudier@club-internet.fr> said:
    > >
    > > > My understanding of Linux architecture is that IO blocks coalescing only
    > > > occurs in ll_rw_blk.c.
    > >
    > > Yes, except for scsi which does its Own Thing, of course.
    >
    > When I imagine a system with a large memory space, for example 1 GB,
    > running several hundreds of processes (thousands?) performing writes, all
    > of them sharing the only 64 requests (NR_REQUEST) in 2.1.128 kernel, I
    > cannot believe that coalescence will work that well.
    > Did I miss something important?

    I agree mostly. A very simple "fix" to this situation would be to make
    the queue longer as you hint. Even make it a tunable kernel parameter
    under /proc. If you have 1 GB of memory you can spare a few bytes for a
    larger queue. Although against this, we can argue that such a large
    system *should* already have an intelligent disk controller (RAID?) that
    has sufficiently large buffers to do these optimizations. Just my 2
    centavos...

    Cheers,

    Rafael


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

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