On Thu, Nov 07 2019 at 2:29pm -0500, Maged Mokhtar <mmokhtar@xxxxxxxxxxx> wrote: > > > 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 ..? It does, so if you can demonstrate that using suspend/reload/resume vs your messages is cause for reduced overall performance that would help justify your patch. But if you're having to tune so actively that it matters I'd argue the tuning is a workaround for a more systemic issue in the dm-writecaache code. Thanks, Mike -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
