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