Page 1 of 3 123 LastLast
Results 1 to 10 of 21

Thread: Stll wrong i/o scheduler used in 17.04?

  1. Back To Top    #1
    Newbie
    Join Date
    Apr 2017
    Posts
    1
    Threads
    1
    Local Date
    Jan 10th 2018
    Local Time
    01:20 PM

    Stll wrong i/o scheduler used in 17.04?

    Just wanted to know from people who had it installed, if this here is fixed in 17.04?

    Unlike Ubuntu and Ubuntu GNOME, Kubuntu 16.10 uses the ‘CFQ’ I/O scheduler (this is utility that controls read & write requests to the main storage device) and under it the responsiveness was horrible! Twice the system completely got stuck for about 3-4 seconds and most of ‘heavyweight’ applications were only opened after the file copy finished. There was also a big delay for VLC to open the multimedia file too.
    However, then I changed the I/O scheduler to ‘deadline’ (the Kernel comes with 3 actually), one that’s used by Ubuntu & Ubuntu GNOME by default, rebooted the computer and ran the test again. And after the ‘switch’ the responsiveness was so impressive that I would say that it was even slightly better than what I observed in Ubuntu & Ubuntu GNOME!
    See article here: http://www.hecticgeek.com/2016/11/ub...rs-comparison/
    He normally knows what he is talking about..

    Because the tests otherwise were super promising. Could see myself using KDE again after ten years, if such things get fixed, because KDE5 itself seems to be tweaked quite well in the meantime

  2. Back To Top    #2
    Esteemed Member acheron's Avatar
    Join Date
    May 2016
    Location
    UK
    Posts
    527
    Threads
    19
    Local Date
    Jan 10th 2018
    Local Time
    01:20 PM
    Need to find a better reference for this, but...

    http://askubuntu.com/questions/78444...rs-to-deadline

    We've moved to using CFQ as default for the Ubuntu Zesty 4.10 kernel and also enabled the new CONFIG_BLK_WBT_MQ (Multiqueue writeback throttling) as this resolves the dirty cache writeback issues with slow devices such as flash devices. – Colin Ian King Mar 13 at 22:27
    You can obviously changes rules to override that default.
    Last edited by acheron; Apr 9th 2017 at 10:49 AM.
    On #kubuntu-devel & #kubuntu on irc.freenode.net - IRC Nick: acheronuk - Launchpad ID: click

  3. Back To Top    #3
    Ascendant GreyGeek's Avatar
    Join Date
    Feb 2009
    Location
    Lincoln, NE
    Posts
    13,723
    Threads
    978
    Local Date
    Jan 10th 2018
    Local Time
    07:20 AM
    Quote Originally Posted by mpathy View Post
    Just wanted to know from people who had it installed, if this here is fixed in 17.04?



    See article here: http://www.hecticgeek.com/2016/11/ub...rs-comparison/
    He normally knows what he is talking about..

    Because the tests otherwise were super promising. Could see myself using KDE again after ten years, if such things get fixed, because KDE5 itself seems to be tweaked quite well in the meantime
    While Gayan praises the "deadline" scheduling in that article he blames it in another and changes scheduling to cfq.

    When someone in the talkbacks responded that deadline was still better his response was:
    Thank you for the input. However, ‘Deadline’ is known to perform better under SSDs. For rotating disk drives, in my limited practical experience, even though ‘Deadline’ used to perform better in the past, these days, I prefer ‘CFQ’, it just seems to be more fair and responsive. But if it changes in the future, then yes I’ll switch back to ‘Deadline’…
    Maybe he's changed his mind again over the last two years? Or has the deadline scheduling algorithm improved? It's an easy test He shows, in the second article, how to change the I/O Scheduler so that you can find out for yourself on YOUR machine which is faster for the stuff you do..
    Last edited by GreyGeek; Apr 9th 2017 at 11:40 AM.
    There is no truth in the news, and no news in the truth.

  4. Back To Top    #4
    Kubuntu as Second Language wizard10000's Avatar
    Join Date
    Sep 2009
    Location
    midwestern us
    Posts
    1,474
    Threads
    87
    Local Date
    Jan 10th 2018
    Local Time
    08:20 AM
    I use a udev rule that sets the scheduler to deadline for non-rotating disks. Swiped from

    https://wiki.debian.org/SSDOptimization

    Code:
    # set deadline scheduler for non-rotating disks
    
    ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"
    we see things not as they are, but as we are.
    -- anais nin

  5. Back To Top    #5
    Kubuntu as Second Language
    Join Date
    Apr 2008
    Location
    Auckland, New Zealand
    Posts
    1,026
    Threads
    43
    Local Date
    Jan 11th 2018
    Local Time
    02:20 AM
    Weird that this has come up again. Way back, this bit me hard when copying to a USB stick or SD card; desktop I/O starvation occurred rendering the system unusable, to the point where KDE and the OS itself were throwing wobblies. I couldn't understand why anyone thought this was ok; CFQ was a complete dog, total fail, in some circumstances, not just a bit slower. Several bugs were filed showing terrible performance with CFQ, and I concluded that they just didn't believe us.

    Checking,
    Code:
    $ cd /sys/block
    $ for x in ?d?;do echo "$x $(<$x/queue/rotational) $(<$x/queue/scheduler)";done
    sda 1 noop deadline [cfq] 
    sdb 1 noop deadline [cfq] 
    sdc 0 noop [deadline] cfq
    where the SSD has 0 for "rotational", I see that my SSD is using deadline, and the hard disks CFQ. There is a udev rule the opposite of wizard10000's turning on CFQ for "rotational" devices, so in 16.10 deadline is the default.

    Thanks for the warning, all, now I know to check this out when I move to Zesty. Maybe it's academic on my present hardware.
    Regards, John Little

  6. Back To Top    #6
    Kubuntu as Second Language wizard10000's Avatar
    Join Date
    Sep 2009
    Location
    midwestern us
    Posts
    1,474
    Threads
    87
    Local Date
    Jan 10th 2018
    Local Time
    08:20 AM
    Quote Originally Posted by jlittle View Post
    ...so in 16.10 deadline is the default.
    Now I'm gonna have to go look at my laptop when I get home. I run Debian Unstable, and when I set up that udev rule default was CFQ - now I'm not so sure

    Thanks for the info
    we see things not as they are, but as we are.
    -- anais nin

  7. Back To Top    #7
    Ascendant GreyGeek's Avatar
    Join Date
    Feb 2009
    Location
    Lincoln, NE
    Posts
    13,723
    Threads
    978
    Local Date
    Jan 10th 2018
    Local Time
    07:20 AM
    My Neon User Edition using Btrfs reports that my 7200RPM rotational device at sda is "deadline". Maybe cfq is not the default for rotational devices?

    Code:
    cat sys/block/sda/queue/schedule
    Code:
    noop [deadline] cfq
    Does cfq actually work bettor on rotating storage devices when compared to deadline?


    Last edited by GreyGeek; Apr 10th 2017 at 03:18 PM.
    There is no truth in the news, and no news in the truth.

  8. Back To Top    #8
    Ascendant GreyGeek's Avatar
    Join Date
    Feb 2009
    Location
    Lincoln, NE
    Posts
    13,723
    Threads
    978
    Local Date
    Jan 10th 2018
    Local Time
    07:20 AM

    Exclamation

    While researching the deadline vs cfq problem I ran across this kernel source code about blacklisting certain storage mediums.

    They are listed by various types of problems under Linux:
    Code:
    static const struct ata_blacklist_entry ata_device_blacklist [] = {
        /* Devices with DMA related problems under Linux */
        { "WDC AC11000H",    NULL,        ATA_HORKAGE_NODMA },
        { "WDC AC22100H",    NULL,        ATA_HORKAGE_NODMA },
        { "WDC AC32500H",    NULL,        ATA_HORKAGE_NODMA },
        { "WDC AC33100H",    NULL,        ATA_HORKAGE_NODMA },
        { "WDC AC31600H",    NULL,        ATA_HORKAGE_NODMA },
        { "WDC AC32100H",    "24.09P07",    ATA_HORKAGE_NODMA },
        { "WDC AC23200L",    "21.10N21",    ATA_HORKAGE_NODMA },
        { "Compaq CRD-8241B",     NULL,        ATA_HORKAGE_NODMA },
        { "CRD-8400B",        NULL,         ATA_HORKAGE_NODMA },
        { "CRD-848[02]B",    NULL,        ATA_HORKAGE_NODMA },
        { "CRD-84",        NULL,        ATA_HORKAGE_NODMA },
        { "SanDisk SDP3B",    NULL,        ATA_HORKAGE_NODMA },
        { "SanDisk SDP3B-64",    NULL,        ATA_HORKAGE_NODMA },
        { "SANYO CD-ROM CRD",    NULL,        ATA_HORKAGE_NODMA },
        { "HITACHI CDR-8",    NULL,        ATA_HORKAGE_NODMA },
        { "HITACHI CDR-8[34]35",NULL,        ATA_HORKAGE_NODMA },
        { "Toshiba CD-ROM XM-6202B", NULL,    ATA_HORKAGE_NODMA },
        { "TOSHIBA CD-ROM XM-1702BC", NULL,    ATA_HORKAGE_NODMA },
        { "CD-532E-A",         NULL,        ATA_HORKAGE_NODMA },
        { "E-IDE CD-ROM CR-840",NULL,        ATA_HORKAGE_NODMA },
        { "CD-ROM Drive/F5A",    NULL,        ATA_HORKAGE_NODMA },
        { "WPI CDD-820",     NULL,        ATA_HORKAGE_NODMA },
        { "SAMSUNG CD-ROM SC-148C", NULL,    ATA_HORKAGE_NODMA },
        { "SAMSUNG CD-ROM SC",    NULL,        ATA_HORKAGE_NODMA },
        { "ATAPI CD-ROM DRIVE 40X MAXIMUM",NULL,ATA_HORKAGE_NODMA },
        { "_NEC DV5800A",     NULL,        ATA_HORKAGE_NODMA },
        { "SAMSUNG CD-ROM SN-124", "N001",    ATA_HORKAGE_NODMA },
        { "Seagate STT20000A", NULL,        ATA_HORKAGE_NODMA },
        { " 2GB ATA Flash Disk", "ADMA428M",    ATA_HORKAGE_NODMA },
        { "VRFDFC22048UCHC-TE*", NULL,        ATA_HORKAGE_NODMA },
        /* Odd clown on sil3726/4726 PMPs */
        { "Config  Disk",    NULL,        ATA_HORKAGE_DISABLE },
    
        /* Weird ATAPI devices */
        { "TORiSAN DVD-ROM DRD-N216", NULL,    ATA_HORKAGE_MAX_SEC_128 },
        { "QUANTUM DAT    DAT72-000", NULL,    ATA_HORKAGE_ATAPI_MOD16_DMA },
        { "Slimtype DVD A  DS8A8SH", NULL,    ATA_HORKAGE_MAX_SEC_LBA48 },
        { "Slimtype DVD A  DS8A9SH", NULL,    ATA_HORKAGE_MAX_SEC_LBA48 },
    
        /*
         * Causes silent data corruption with higher max sects.
         * http://lkml.kernel.org/g/x49wpy40ysk.fsf@segfault.boston.devel.redhat.com
         */
        { "ST380013AS",        "3.20",        ATA_HORKAGE_MAX_SEC_1024 },
    
        /*
         * These devices time out with higher max sects.
         * https://bugzilla.kernel.org/show_bug.cgi?id=121671
         */
        { "LITEON CX1-JB*-HP",    NULL,        ATA_HORKAGE_MAX_SEC_1024 },
    
        /* Devices we expect to fail diagnostics */
    
        /* Devices where NCQ should be avoided */
        /* NCQ is slow */
        { "WDC WD740ADFD-00",    NULL,        ATA_HORKAGE_NONCQ },
        { "WDC WD740ADFD-00NLR1", NULL,        ATA_HORKAGE_NONCQ, },
        /* http://thread.gmane.org/gmane.linux.ide/14907 */
        { "FUJITSU MHT2060BH",    NULL,        ATA_HORKAGE_NONCQ },
        /* NCQ is broken */
        { "Maxtor *",        "BANC*",    ATA_HORKAGE_NONCQ },
        { "Maxtor 7V300F0",    "VA111630",    ATA_HORKAGE_NONCQ },
        { "ST380817AS",        "3.42",        ATA_HORKAGE_NONCQ },
        { "ST3160023AS",    "3.42",        ATA_HORKAGE_NONCQ },
        { "OCZ CORE_SSD",    "02.10104",    ATA_HORKAGE_NONCQ },
    
        /* Seagate NCQ + FLUSH CACHE firmware bug */
        { "ST31500341AS",    "SD1[5-9]",    ATA_HORKAGE_NONCQ |
                            ATA_HORKAGE_FIRMWARE_WARN },
    
        { "ST31000333AS",    "SD1[5-9]",    ATA_HORKAGE_NONCQ |
                            ATA_HORKAGE_FIRMWARE_WARN },
    
        { "ST3640[36]23AS",    "SD1[5-9]",    ATA_HORKAGE_NONCQ |
                            ATA_HORKAGE_FIRMWARE_WARN },
    
        { "ST3320[68]13AS",    "SD1[5-9]",    ATA_HORKAGE_NONCQ |
                            ATA_HORKAGE_FIRMWARE_WARN },
    
        /* drives which fail FPDMA_AA activation (some may freeze afterwards) */
        { "ST1000LM024 HN-M101MBB", "2AR10001",    ATA_HORKAGE_BROKEN_FPDMA_AA },
        { "ST1000LM024 HN-M101MBB", "2BA30001",    ATA_HORKAGE_BROKEN_FPDMA_AA },
        { "VB0250EAVER",    "HPG7",        ATA_HORKAGE_BROKEN_FPDMA_AA },
    
        /* Blacklist entries taken from Silicon Image 3124/3132
           Windows driver .inf file - also several Linux problem reports */
        { "HTS541060G9SA00",    "MB3OC60D",     ATA_HORKAGE_NONCQ, },
        { "HTS541080G9SA00",    "MB4OC60D",     ATA_HORKAGE_NONCQ, },
        { "HTS541010G9SA00",    "MBZOC60D",     ATA_HORKAGE_NONCQ, },
    
        /* https://bugzilla.kernel.org/show_bug.cgi?id=15573 */
        { "C300-CTFDDAC128MAG",    "0001",        ATA_HORKAGE_NONCQ, },
    
        /* devices which puke on READ_NATIVE_MAX */
        { "HDS724040KLSA80",    "KFAOA20N",    ATA_HORKAGE_BROKEN_HPA, },
        { "WDC WD3200JD-00KLB0", "WD-WCAMR1130137", ATA_HORKAGE_BROKEN_HPA },
        { "WDC WD2500JD-00HBB0", "WD-WMAL71490727", ATA_HORKAGE_BROKEN_HPA },
        { "MAXTOR 6L080L4",    "A93.0500",    ATA_HORKAGE_BROKEN_HPA },
    
        /* this one allows HPA unlocking but fails IOs on the area */
        { "OCZ-VERTEX",            "1.30",    ATA_HORKAGE_BROKEN_HPA },
    
        /* Devices which report 1 sector over size HPA */
        { "ST340823A",        NULL,        ATA_HORKAGE_HPA_SIZE, },
        { "ST320413A",        NULL,        ATA_HORKAGE_HPA_SIZE, },
        { "ST310211A",        NULL,        ATA_HORKAGE_HPA_SIZE, },
    
        /* Devices which get the IVB wrong */
        { "QUANTUM FIREBALLlct10 05", "A03.0900", ATA_HORKAGE_IVB, },
        /* Maybe we should just blacklist TSSTcorp... */
        { "TSSTcorp CDDVDW SH-S202[HJN]", "SB0[01]",  ATA_HORKAGE_IVB, },
    
        /* Devices that do not need bridging limits applied */
        { "MTRON MSP-SATA*",        NULL,    ATA_HORKAGE_BRIDGE_OK, },
        { "BUFFALO HD-QSU2/R5",        NULL,    ATA_HORKAGE_BRIDGE_OK, },
    
        /* Devices which aren't very happy with higher link speeds */
        { "WD My Book",            NULL,    ATA_HORKAGE_1_5_GBPS, },
        { "Seagate FreeAgent GoFlex",    NULL,    ATA_HORKAGE_1_5_GBPS, },
    
        /*
         * Devices which choke on SETXFER.  Applies only if both the
         * device and controller are SATA.
         */
        { "PIONEER DVD-RW  DVRTD08",    NULL,    ATA_HORKAGE_NOSETXFER },
        { "PIONEER DVD-RW  DVRTD08A",    NULL,    ATA_HORKAGE_NOSETXFER },
        { "PIONEER DVD-RW  DVR-215",    NULL,    ATA_HORKAGE_NOSETXFER },
        { "PIONEER DVD-RW  DVR-212D",    NULL,    ATA_HORKAGE_NOSETXFER },
        { "PIONEER DVD-RW  DVR-216D",    NULL,    ATA_HORKAGE_NOSETXFER },
    
        /* devices that don't properly handle queued TRIM commands */
        { "Micron_M500_*",        NULL,    ATA_HORKAGE_NO_NCQ_TRIM |
                            ATA_HORKAGE_ZERO_AFTER_TRIM, },
        { "Crucial_CT*M500*",        NULL,    ATA_HORKAGE_NO_NCQ_TRIM |
                            ATA_HORKAGE_ZERO_AFTER_TRIM, },
        { "Micron_M5[15]0_*",        "MU01",    ATA_HORKAGE_NO_NCQ_TRIM |
                            ATA_HORKAGE_ZERO_AFTER_TRIM, },
        { "Crucial_CT*M550*",        "MU01",    ATA_HORKAGE_NO_NCQ_TRIM |
                            ATA_HORKAGE_ZERO_AFTER_TRIM, },
        { "Crucial_CT*MX100*",        "MU01",    ATA_HORKAGE_NO_NCQ_TRIM |
                            ATA_HORKAGE_ZERO_AFTER_TRIM, },
        { "Samsung SSD 8*",        NULL,    ATA_HORKAGE_NO_NCQ_TRIM |    <--------- I FOUND THIS INTERESTING! Samsung SSD 8** series with TRIM problems.
                            ATA_HORKAGE_ZERO_AFTER_TRIM, },
        { "FCCT*M500*",            NULL,    ATA_HORKAGE_NO_NCQ_TRIM |
                            ATA_HORKAGE_ZERO_AFTER_TRIM, },
    
        /* devices that don't properly handle TRIM commands */
        { "SuperSSpeed S238*",        NULL,    ATA_HORKAGE_NOTRIM, },
    
        /*
         * As defined, the DRAT (Deterministic Read After Trim) and RZAT
         * (Return Zero After Trim) flags in the ATA Command Set are
         * unreliable in the sense that they only define what happens if
         * the device successfully executed the DSM TRIM command. TRIM
         * is only advisory, however, and the device is free to silently
         * ignore all or parts of the request.
         *
         * Whitelist drives that are known to reliably return zeroes
         * after TRIM.
         */
    
        /*
         * The intel 510 drive has buggy DRAT/RZAT. Explicitly exclude
         * that model before whitelisting all other intel SSDs.
         */
        { "INTEL*SSDSC2MH*",        NULL,    0, },
    
        { "Micron*",            NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },
        { "Crucial*",            NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },
        { "INTEL*SSD*",         NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },
        { "SSD*INTEL*",            NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },
        { "Samsung*SSD*",        NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },
        { "SAMSUNG*SSD*",        NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },
        { "ST[1248][0248]0[FH]*",    NULL,    ATA_HORKAGE_ZERO_AFTER_TRIM, },
    
        /*
         * Some WD SATA-I drives spin up and down erratically when the link
         * is put into the slumber mode.  We don't have full list of the
         * affected devices.  Disable LPM if the device matches one of the
         * known prefixes and is SATA-1.  As a side effect LPM partial is
         * lost too.
         *
         * https://bugzilla.kernel.org/show_bug.cgi?id=57211
         */
        { "WDC WD800JD-*",        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },
        { "WDC WD1200JD-*",        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },
        { "WDC WD1600JD-*",        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },
        { "WDC WD2000JD-*",        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },
        { "WDC WD2500JD-*",        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },
        { "WDC WD3000JD-*",        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },
        { "WDC WD3200JD-*",        NULL,    ATA_HORKAGE_WD_BROKEN_LPM },
    
        /* End Marker */
        { }
    };
    Checking the Samsung 8* bug I found that it was fixed.

    So, which is better, cfq or deadline?
    Basically, neither, for the 4.8.0-21 kernel using the EXT4 fs, although deadline is a dog on the EXT3.
    http://kernel.ubuntu.com/~cking/fs-t...-os/index.html

    Sadly, no results are given for the Btrfs.
    So, I will just leave mine set to deadline, which is the default for the 16.04 release.

    I was wondering about the NOOP schedular and found this on the WIkipedia article:
    However, NOOP is not necessarily the preferred I/O scheduler for the above scenarios. As with any performance tuning, all guidance will be based on observed work load patterns (undermining one's ability to create simplistic rules of thumb). If there is contention for available I/O bandwidth from other applications, it is still possible that other schedulers will generate better performance by virtue of more intelligently carving up that bandwidth for the applications deemed most important. For example, running an LDAP directory server may benefit from deadline's read preference and latency guarantees. At the same time, a user with a desktop system running many different applications may want to have access to CFQ's tunables or its ability to prioritize bandwidth for particular applications over others (ionice).
    While watching some processes on KSysmonitor I noticed that delays appeared to be cause by "disk sleep" indications. I changed the HD scheduling to improve performance, but didn't notice any improvements. "disk sleep" msgs still appeared. Maybe I should try cfq.

    From RH's CFQ configuration documentation (I don't know how much of this applies to Ubuntu/Kubuntu):
    Code:
    6.3.5. Tuning the cfq scheduler
    
    
    
    
    When cfq is in use, processes are placed into three classes: real time, best effort, and idle. All real time processes are scheduled before any best effort processes, which are scheduled before any idle processes. By default, processes are classed as best effort. You can manually adjust the class of a process with the ionice command.
    You can further adjust the behavior of the cfq scheduler with the following parameters. These parameters are set on a per-device basis by altering the specified files under the /sys/block/devname/queue/iosched directory.
    
    ⁠back_seek_max
    The maximum distance in kilobytes that cfq will perform a backward seek. The default value is 16 KB. Backward seeks typically damage performance, so large values are not recommended.
    
    ⁠back_seek_penalty
    The multiplier applied to backward seeks when the disk head is deciding whether to move forward or backward. The default value is 2. If the disk head position is at 1024 KB, and there are equidistant requests in the system (1008 KB and 1040 KB, for example), the back_seek_penalty is applied to backward seek distances and the disk moves forward.
    
    ⁠fifo_expire_async
    The length of time in milliseconds that an asynchronous (buffered write) request can remain unserviced. After this amount of time expires, a single starved asynchronous request is moved to the dispatch list. The default value is 250 milliseconds.
    ⁠
    fifo_expire_sync
    The length of time in milliseconds that a synchronous (read or O_DIRECT write) request can remain unserviced. After this amount of time expires, a single starved synchronous request is moved to the dispatch list. The default value is 125 milliseconds.
    
    ⁠group_idle
    This parameter is set to 0 (disabled) by default. When set to 1 (enabled), the cfq scheduler idles on the last process that is issuing I/O in a control group. This is useful when using proportional weight I/O control groups and when slice_idle is set to 0 (on fast storage).
    
    ⁠group_isolation
    This parameter is set to 0 (disabled) by default. When set to 1 (enabled), it provides stronger isolation between groups, but reduces throughput, as fairness is applied to both random and sequential workloads. When group_isolation is disabled (set to 0), fairness is provided to sequential workloads only. For more information, see the installed documentation in /usr/share/doc/kernel-doc-version/Documentation/cgroups/blkio-controller.txt.
    
    ⁠low_latency
    This parameter is set to 1 (enabled) by default. When enabled, cfq favors fairness over throughput by providing a maximum wait time of 300 ms for each process issuing I/O on a device. When this parameter is set to 0 (disabled), target latency is ignored and each process receives a full time slice.
    
    ⁠quantum
    This parameter defines the number of I/O requests that cfq sends to one device at one time, essentially limiting queue depth. The default value is 8 requests. The device being used may support greater queue depth, but increasing the value of quantum will also increase latency, especially for large sequential write work loads.
    
    ⁠slice_async
    This parameter defines the length of the time slice (in milliseconds) allotted to each process issuing asynchronous I/O requests. The default value is 40 milliseconds.
    
    ⁠slice_idle
    This parameter specifies the length of time in milliseconds that cfq idles while waiting for further requests. The default value is 0 (no idling at the queue or service tree level). The default value is ideal for throughput on external RAID storage, but can degrade throughput on internal non-RAID storage as it increases the overall number of seek operations.
    
    ⁠slice_sync
    This parameter defines the length of the time slice (in milliseconds) allotted to each process issuing synchronous I/O requests. The default value is 100 ms.
    
    6.3.5.1. Tuning cfq for fast storage
    
    
    
    
    The cfq scheduler is not recommended for hardware that does not suffer a large seek penalty, such as fast external storage arrays or solid-state disks. If your use case requires cfq to be used on this storage, you will need to edit the following configuration files:
    
    
    • Set /sys/block/devname/queue/ionice/slice_idle to 0
    • Set /sys/block/devname/queue/ionice/quantum to 64
    • Set /sys/block/devname/queue/ionice/group_idle to 1
    Last edited by GreyGeek; Apr 10th 2017 at 04:11 PM.
    There is no truth in the news, and no news in the truth.

  9. Back To Top    #9
    Kubuntu as Second Language wizard10000's Avatar
    Join Date
    Sep 2009
    Location
    midwestern us
    Posts
    1,474
    Threads
    87
    Local Date
    Jan 10th 2018
    Local Time
    08:20 AM
    Quote Originally Posted by GreyGeek View Post
    ...Does cfq actually work better on rotating storage devices when compared to deadline?
    Maybe. Found a pretty good read here -

    http://stackoverflow.com/questions/9...dline-and-noop

    The CFQ scheduler allows you to set priorities via the ionice tool or the ioprio_set system call. This allows giving precedence to some processes or forcing others to do their IO only when the system's block devices are relatively idle. The queues are implemented by segregating the IO requests from processes into queues, and handling the requests from each queue similar to CPU scheduling. Details on configuring it can be found in https://www.kernel.org/Documentation...fq-iosched.txt.

    The deadline scheduler by contrast looks at all writes from all processes at once; it sorts the writes by sector number, and writes them all in linear fashion. The deadlines means that it tries to write each block before its deadline expires, but within those deadlines, is free to re-arrange blocks as it sees fit. Details on configuring it can be found in https://www.kernel.org/Documentation...ne-iosched.txt
    From what I've read here and in linked kernel.org documents, it seems to me that using deadline on a rotating disk *may* cause stuttering that wouldn't happen with CFQ. SSD are fast enough that forcing disk writes before the deadline expires is probably going to have minimal impact on performance.
    we see things not as they are, but as we are.
    -- anais nin

  10. Back To Top    #10
    Ancient oshunluvr's Avatar
    Join Date
    Feb 2010
    Location
    New Bern, NC USA
    Posts
    8,798
    Threads
    308
    Local Date
    Jan 10th 2018
    Local Time
    08:20 AM
    The Ubuntu Kernel testing team says currently, deadline is best for the current kernels. Of course, if your use is non-standard you might see a difference: http://kernel.ubuntu.com/~cking/fs-tests/feb-2017/
    Please Read Me
    Be not the first by whom the new are tried, Nor yet the last to lay the old aside. - Alexander Pope, An Essay on Criticism, 1711

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •