lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <4F84718C.4010706@gmail.com>
Date:	Tue, 10 Apr 2012 19:44:44 +0200
From:	Xose Vazquez Perez <xose.vazquez@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] block: Change default IO scheduler to deadline except
 SATA

Vivek Goyal wrote:

 > I am wondering if CFQ as default scheduler is still the right choice. CFQ
 > generally works well on slow rotational media (SATA?). But often
 > underperforms on faster storage (storage arrays, PCIE SSDs, virtualized
 > disk in linux guests etc). People often put logic in user space to tune their
 > systems and change IO scheduler to deadline to get better performance on
 > faster storage.
 >
 > Though there is not one good answer for all kind of storage and for all
 > kind of workloads, I am wondering if we can provide a better default and
 > that is change default IO scheduler to "deadline" except SATA.
 >
 > One can argue that some SAS disks can be slow too and benefit from CFQ. Yes,
 > but default IO scheduler choice is not perfect anyway. It just tries to
 > cater to a wide variety of use cases out of the box.
 >
 > So I am throwing this patch out see if it flies. Personally, I think it
 > might turn out to be a more reasonable default.

done time ago for dasd devices.

chuchi:~/curre/linux-2.6 $ grep -ri deadline drivers/s390/block/*
drivers/s390/block/dasd.c:      rc = elevator_init(block->request_queue, "deadline");
drivers/s390/block/Kconfig:     select IOSCHED_DEADLINE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ