Re: disk/crypto performance regression 2.6.31 -> 2.6.32 (mmap problem?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



M> You're right, it doesn't say that anymore in 2.6.31, so I think I'm 
M> indeed running with barriers on.

When barriers were added to ext4, I saw a similar slowdown on lock- and
sync- heavy workloads.

Based on a recent thread on the ext4 list I've started using deadline
rather than cfq on that disk.  There are some slowdowns on that disk's
other partition, but the overall throughput is significantly better than
using the combination of cfq, ext4 and barriers.

You might want to test out deadline and/or noop.

Cf:  /sys/block/*/queue/scheduler

-JimC
-- 
James Cloos <cloos@xxxxxxxxxxx>         OpenPGP: 1024D/ED7DAEA6

--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel

[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux