On Sunday, 12 July 2020 12:38:22 BST William Kenworthy wrote: > On 12/7/20 6:03 pm, Nikos Chantziaras wrote: > > echo bfq > /sys/block/sda/queue/schedule > > Thanks for the hints, > > ive gone with schedtool and ionice for now (seems to be working) and > will configure that as the defaults when this run finishes. I have not > built the bfq scheduler in this kernel so will give that a try later - > its currently using mq-deadline with a WD blue SSD (will bfq be better > than a deadline on an ssd? - will try it and see). It has 4g ram and 4g > swap with about half in use - in normal running swap isn't used much, if > at all.
BFQ manages the I/O pipe more effectively/efficiently, so if the pipe gets full due to e.g. heavy swapping, you'll see an improvement. However, with an SSD the improvement will be less noticeable than with a spinning disk and with an NVMe even less. > As well as emerge, the io load is also coming from the network as I have > 3x1g bonded interfaces routing busy vlans including a moosefs SAN and a > 100mhz uplink which was suffering delays and timeouts. The root cause > is trying to do too much with too little - :) > > BillK Network storage will be managed by the remote kernel, so your atom's scheduler won't help with that.
signature.asc
Description: This is a digitally signed message part.
