On Wed, 31 Aug 2016, Mark Brown wrote: [...] > I personally feel that given that it looks like this is all going to > take a while it'd still be good to merge BFQ at least as an alternative > scheduler so that people can take advantage of it while the work on > modernising everything to use blk-mq - that way we can hopefully improve > the state of the art for users in the short term or at least help get > some wider feedback on how well this works in the real world > independently of the work on blk-mq. I would like to chime in agree fervently with Mark. We have a pair of very busy hypervisors with a complicated block stack integrating bcache, drbd, LVM, dm-thin, kvm, ggaoed (AoE target), zram swap, continuous block-layer backups and snapshot verifies to tertiary storage, cgroup block IO throttled limits, and lots of hourly dm-thin snapshots replicated to tertiary storage. All of this is performed under heavy memory pressure (35-40% swapped out to zram). The systems work moderately well under cfq, but *amazingly well* using BFQ. I like BFQ so much that I've backported v8r2 to Linux v4.1 [1]. +1 to upstream this as a new scheduler without replacing CFQ. Including BFQ would be a boon for Linux and the community at large. -- Eric Wheeler [1] Based on Linux v4.1-rc1, it cleanly merges forward into v4.7: https://bitbucket.org/ewheelerinc/linux/branch/v4.1-rc1-bfq-v8 git pull https://bitbucket.org/ewheelerinc/linux.git v4.1-rc1-bfq-v8 -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
