On 07/11/2019 21:09, Mike Snitzer wrote:
On Thu, Nov 07 2019 at 1:55pm -0500,
Maged Mokhtar <mmokhtar@xxxxxxxxxxx> wrote:
On 06/11/2019 17:08, Mike Snitzer wrote:
On Tue, Nov 05 2019 at 4:19pm -0500,
Maged Mokhtar <mmokhtar@xxxxxxxxxxx> 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 ..?
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
