[dm-devel] [PATCH] dm cache: add writeback watermarks

[swilton at fluentit.com.au]

Quoting Steven Wilton <swilton at fluentit.com.au>:

> On 8/03/2016 11:23 PM, Joe Thornber wrote:
>> On Tue, Mar 08, 2016 at 10:52:42PM +0800, Steven Wilton wrote:
>>> Add 2 new options to the dm-cache code, writeback_low_watermark to
>>> keep a section of the cache dirty in order to reduce the amount
>>> of data being migrated from the cache to the origin, and
>>> writeback_high_watermark to allow a threshold to be set where the
>>> dirty cache entries are flushed as quick as possible.
>> Right. mq is being removed, or rather becoming an alias for smq (patch
>> posted a couple of weeks ago to dm-devel).
>>
>> smq already has a writeback delay to prevent writeback of frequently
>> changing data:
>>
>> https://github.com/jthornber/linux-2.6/blob/thin-dev/drivers/md/dm-cache-policy-smq.c#L338
>> https://github.com/jthornber/linux-2.6/blob/thin-dev/drivers/md/dm-cache-policy-smq.c#L850
>> https://github.com/jthornber/linux-2.6/blob/thin-dev/drivers/md/dm-cache-policy-smq.c#L876
>>
>> and has a threshold/watermark that triggers more aggressive writeback:
>>
>> https://github.com/jthornber/linux-2.6/blob/thin-dev/drivers/md/dm-cache-policy-smq.c#L1463
>>
>> I think this decision belongs in the policy, you've moved it to the
>> core.
>>
>> Also I'm trying to avoid introducing tunables to the interface.  It's
>> not enough to document what the tunables do, but we also have to
>> explain how people should arrive at the correct values for their work
>> loads.
>>
>> Have you tried smq?  What work load are you running?  Does your patch
>> improve things?
>>
>> - Joe
>>
> Hi Joe,
>
> I'm very new to dm-devel, and was not aware of the smq patch.  I  
> will base any new patches off this work.  I did just had a look, and  
> am I correct in saying that the smq patch will still be limited to  
> migrating data at the migration_threshold rate?
>
> I have not tried my patch on any production data yet, since I wanted  
> to make sure I had not done anything obviously that was going to eat  
> my data first :)   If it is possible to confirm that I'm not doing  
> anything silly, I am happy to both run some benchmarks and see the  
> difference on production workloads, and post any results.
>
> My goal is to reduce the number of writebacks occurring, and I still  
> think that having a low watermark is the best way to achieve.  I  
> know that I was reading some notes form the bcache developer, who  
> found that having a low watermark helped bcache.  The one  
> improvement that I can think of would be to flush below the low  
> watermark if the I/O load is below a particular threshold.
>
> If you could have a look at my patch to confirm that it's not doing  
> anything bad, I will update my branch to use smq and develop a patch  
> against that, and run some tests on my data before posting another  
> patch.
>
> regards
>
> Steven
>

Having had a look at the current code, it looks like the issues I was  
trying to solve have been addressed in more recent changes to the SMQ  
and target.

 From what I can see, the origin tracker has been added to allow  
migrations to be handled differently when the target is busy, which  
will keep more of the cached blocks dirty under normal I/O load, but  
still allow them to be flushed under light/idle I/O load (which is  
what I was aiming for).

I will start the process of getting these changes running on our dev  
system and then production, and see what difference it makes.

For the record, the workload is mixed between live offsite replication  
and storage for various virtual machines.

thanks

Steve