lkml.org 
[lkml]   [2011]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch]cfq-iosched: delete deep seeky queue idle logic
    On Fri, Sep 16, 2011 at 08:04:49AM +0200, Corrado Zoccolo wrote:
    > On Fri, Sep 16, 2011 at 5:09 AM, Shaohua Li <shaohua.li@intel.com> wrote:
    > > Recently Maxim and I discussed why his aiostress workload performs poorly. If
    > > you didn't follow the discussion, here are the issues we found:
    > > 1. cfq seeky dection isn't good. Assume a task accesses sector A, B, C, D, A+1,
    > > B+1, C+1, D+1, A+2...Accessing A, B, C, D is random. cfq will detect the queue
    > > as seeky, but since when accessing A+1, A+1 is already in disk cache, this
    > > should be detected as sequential really. Not sure if any real workload has such
    > > access patern, and seems not easy to have a clean fix too. Any idea for this?
    >
    > Not all disks will cache 4 independent streams, we can't make that
    > assumption in cfq.
    > The current behaviour of assuming it as seeky should work well enough,
    > in fact it will be put in the seeky tree, and it can enjoy the seeky
    > tree quantum of time. If the second round takes a short time, it will
    > be able to schedule a third round again after the idle time.
    > If there are other seeky processes competing for the tree, the cache
    > can be cleared by the time it gets back to your 4 streams process, so
    > it will behave exactly as a seeky process from cfq point of view.
    > If the various accesses were submitted in parallel, the deep seeky
    > queue logic should kick in and make sure the process gets a sequential
    > quantum, rather than sharing it with other seeky processes, so
    > depending on your disk, it could perform better.

    I think I agree that we probably can not optimize CFQ for cache behavior
    without even knowing what a cache on a device might be doing. There
    are no gurantees that by making this 4 stream process sequential you will
    get better throughput in fact additional idling can kill the throughput
    on faster storage. It probably should be left to the device cache to
    optimize for such IO patterns.

    Thanks
    Vivek


    \
     
     \ /
      Last update: 2011-09-16 15:39    [W:0.020 / U:89.632 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site