On Wed, Sep 20, 2017 at 1:24 PM, Coly Li <i@xxxxxxx> wrote: > My point is, we should have exact real data to approve this change makes > things better. Better means a problem gets solved. For this single > patch, I see description on how the change is made, I don't see what > exact problem to be solved. OK. With this change, my workloads always do fewer IOPs during quiet times. It often waits 2.5 seconds, instead of waiting 1 second. The utilization is clearly more constant, because when it writes more than 4k, it leaves the disk alone for longer. Before, you were concerned that setting the minimum writeback rate above 1 sector would significantly impact performance, so this variant was chosen to **always do less I/O**. It should be fairly evident that it does this :/ When it writes back a 4k key (the smallest key I get), it behaves exactly the same and sleeps one second. When it writes back a longer key, it waits longer. My other motivation is-- the writeback behavior is problematic-- right now it writes at exactly the wrong speed for the IronWolf disks-- it waits barely long enough for things to go into a power-saving / safe shutdown mode (unloading the head actuator to the side). The current behavior maximizes the number of load/unload cycles that the disk undergoes. I don't have proof that this leads to earlier drive failure, but in general "clunk clunk clunk" is not good. At least with this code it will do it half as much, pending further changes to mitigate this more. > The P.I controller patch makes sense. But for this single patch, change > minimum writeback rate from 1 to 8, and next delay timeout from 1 to 2.5 > seconds, I don't see this modification is path towards getting things > more understandable, before we see real data to approve it. > > This is why I said: again, I'd like to see exact data here. Let me > discuss with Micheal for more details. What do you want to see, iostat 1 of background writeback with current code showing it is never doing less than 4k to the backing disks? Because I have several thousand seconds of that. If you have any installation of current bcache you should be able to do just run it and see. Mike -- To unsubscribe from this list: send the line "unsubscribe linux-bcache" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html