[dm-devel] dm-writecache: change config parameters using messages
Maged Mokhtar
mmokhtar at petasan.org
Thu Nov 7 19:29:56 UTC 2019
On 07/11/2019 21:09, Mike Snitzer wrote:
> On Thu, Nov 07 2019 at 1:55pm -0500,
> Maged Mokhtar <mmokhtar at petasan.org> wrote:
>
>>
>>
>> On 06/11/2019 17:08, Mike Snitzer wrote:
>>> On Tue, Nov 05 2019 at 4:19pm -0500,
>>> Maged Mokhtar <mmokhtar at petasan.org> wrote:
>>>
>>>> Gentle ping please.
>>>>
>>>> It could add flexibility in changing cache parameters after device creation.
>>>
>>> I'm inclined to _not_ take this type of change.
>>>
>>> Why isn't changing the config parameters via table reload viable for
>>> you?
>>>
>>
>>
>> Hi Mike,
>>
>> Thank you for your response. The main issue is to enable setting
>> some config parameters while the device is mounted and running and
>> avoid calling target ctr() by sending parameter changes via
>> messages. A similar setup was used in dm-cache.
>>
>> The reason is that tuning the write cache may require run time
>> changes. If un-tuned we can observes periods of spikes and/or step
>> like disk utilization on the slow device during writeback using
>> iostat, and these spikes correspond to periods of increased client
>> io latency. Utilization can be tuned by varying the number of active
>> writeback jobs + the gap between high and low marks to achieve a
>> smooth high utilization. Such tuning is difficult to do when
>> creating the cache device as it depends on the hardware and io
>> workload. We are hoping to use some userspace monitoring and tuning
>> tool to periodically adjust these values while the device is
>> running.
>
> I think you're missing that any actively used DM device can be
> suspended, table reloaded, resumed. So the tuning at runtime is still
> possible, it just requires more steps.
>
> And I'm saying that unless/until there is a better reason other than
> "dm-cache allowed tuning via messages" I'm not interested in having
> multiple methods for tuning dm-writecache.
>
> Mike
>
just for my understanding, does not table reload call _ctr() and
re-initializes things like threads/read metadada ..?
More information about the dm-devel
mailing list