lkml.org 
[lkml]   [2010]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: CFQ and dm-crypt
    On 10/25/10 22:59, Vivek Goyal wrote:
    > Richard,
    >
    > So what problem are you facing? I know you are referring to CFQ ioprio not
    > working with dm targets but how does it impact you? So it is not about
    > overall disk performance or any slow down with dm-crypt target but just
    > about prioritizing your IO over other?

    The ioprio not working is probably the biggest problem (since it is used
    quite a lot for background tasks like desktop indexing services). But
    also the overall performance is worse. I didn't do a rigorous
    benchmarking, but tried a following simple test to see the impact of my
    dm-crypt patch:

    test-write:

    SIZE=640


    KERN=`uname -r`
    ((time /bin/bash -c "dd if=/dev/zero bs=1M count=64 \
    of=normal.tst oflag=direct") 1>$KERN-write-normal 2>&1) |
    ((time /bin/bash -c "ionice -c 3 dd if=/dev/zero bs=1M \
    count=64 of=idle.tst oflag=direct") 1>$KERN-write-idle 2>&1)

    Times for vanilla kernel (with CFQ) were 5.24s for idle and 5.38s for
    normal, times for patched kernel were 4.9s for idle and 3.13s for
    normal. A similar test for reading showed even bigger differences:
    vanilla kernel has 8.5s for idle as well as 8.5s for normal, patched
    kernel has 4.2s for idle and 2.1s for normal.

    So it seems that CFQ is behaving really badly if it is not able to see
    which process is doing the IO (and sees kcryptd everywhere). As far as I
    understood, there is no point in using CFQ in that case and it is much
    better to use other scheduler in this situation.


    Richard


    \
     
     \ /
      Last update: 2010-10-26 10:39    [W:0.021 / U:93.032 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site