<br><br>On Wednesday, March 2, 2016, Vivek Goyal <<a href="mailto:vgoyal@redhat.com">vgoyal@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Mar 02, 2016 at 08:03:10PM +0200, Nikolay Borisov wrote:<br>
> Thanks for the patch I will likely have time to test this sometime next week.<br>
> But just to be sure - the expected behavior would be that processes<br>
> writing to dm-based devices would experience the fair-shair<br>
> scheduling of CFQ (provided that the physical devices that back those<br>
> DM devices use CFQ), correct?<br>
<br>
Nikolay,<br>
<br>
I am not sure how well it will work with CFQ of underlying device. It will<br>
get cgroup information right for buffered writes. But cgroup information</blockquote><div><br></div><div> Right, what's your definition of  buffered writes? My mental model is that when a process submits a write request to a dm device , the bio is going to be put on a devi e workqueue which would then  be serviced by a background worker thread and later the submitter notified. Do you refer to this whole gamut of operations as buffered writes?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
for reads and direct writes will come from submitter's context and if dm<br>
layer gets in between, then many a times submitter might be a worker<br>
thread and IO will be attributed to that worker's cgroup (root cgroup).</blockquote><div><br></div><div>Be that as it may, proivded that the worker thread is in the  'correct' cgroup,  then the appropriate babdwidth policies should apply, no? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Give it a try anyway.</blockquote><div><br></div><div>Most certainly I will :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks<br>
Vivek<br>
</blockquote>