[lkml]   [2006]   [Jul]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: CFQ will be the new default IO scheduler - why?
    Arjan van de Ven wrote:
    > > > Should there be a default scheduler per filesystem? As some
    > > > filesystems may perform better/worse with one over another?
    > >
    > > It's currently perDevice, and should probably be extended to perMount.
    > Hi,


    > per mount is going to be "not funny". I assume the situation you are
    > aiming for is the "3 partitions on a disk, each wants its own elevator".
    > The way the kernel currently works is that IO requests the filesystem
    > does are first flattened into an IO for the entire device (eg the
    > partition mapping is done) and THEN the IO scheduler gets involved to
    > schedule the IO on a per disk basis.

    IC. That probably explains why concurrent io-procs have such a hard time
    getting through to the disk. They probably just hang in the flatting phase,
    waiting for something to take care of their requests.

    > The 2.4 kernel did this the other way around, and it was really a bad
    > idea (no fairness, less optimal scheduling all around due to less
    > visibility into what the disk is really doing, several hardware
    > properties such as TCQ depth that affect scheduling IOs are truely per
    > disk not per partition etc etc)
    > So I don't think it's likely that per mount is really an option right
    > now..

    Probably true as it stands right now, but extending io-sched semantics to be
    filesystem aware in the "flattening/partition mapping" phase could improve
    performance a lot.



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

     \ /
      Last update: 2006-07-25 06:59    [W:0.024 / U:0.140 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site