[dm-devel] [PATCH v3] dm-cache watermarks
Steven Wilton
swilton at fluentit.com.au
Tue Mar 8 15:16:51 UTC 2016
On 07/03/16 22:17, Mike Snitzer wrote:
> On Sun, Mar 06 2016 at 4:39am -0500,
> Steven Wilton <swilton at fluentit.com.au> wrote:
>
>> I realised that I over-thought the original logic. The attached
>> patch is much simpler - write back dirty cache entries at the
>> migration threshold rate when we are over the low watermark, and we
>> write back as fast as possible when we go over the high watermark.
>>
>> The current behaviour can be replicated by setting the high
>> watermark to 100, and the low watermark to 0.
>>
>> regards
>>
>> Steven
> These should default to current behavior (100 and 0 respectively, like
> you mentioned above).
>
> This change needs an accompanying Documentation update. It also needs a
> proper path header to accurately convey the scope of the change.
>
> Please post v4 with these changes and then I'll take a closer look (as
> I'm sure Joe will). But please be aware that in general we want less
> knobs, not more.
>
> Thanks,
> Mike
>
>
Thanks for getting back to me on this. I have just submitted the patch
from git (after reading up on how). Can you please confirm that the new
patch is in the correct format?
If you want less knobs, then the high watermark may not be much use, and
I can remove it from the patch. The initial request was mainly for a
review to make sure I have not done anything obviously wrong that will
lead to data corruption.
I am happy to run some benchmarks on before and after to quantify any
performance gains.
I started looking into this because I noticed an increase in both disk
busy time and data being written to the origin device after I enabled
dm-cache on a production system. The overall performance feels better
even though the origin device is busier, but I am most interested to see
what effect the low watermark has on this system.
I have also had a thought on the stats emitted by dm-cache, and think
that it would be useful to export the number of write hits on already
dirty blocks so we can see how efficient the writeback has been at
avoiding writes to the origin. What is your view on changing the output
format here? If the output format cannot be changed, would you consider
re-defining a write hit in writeback mode as a hit on an already dirty
block, since this is the only scenario where I/O is avoided on the
origin device?
regards
Steve
More information about the dm-devel
mailing list