<div dir="ltr">Hi Joe,<div><br></div><div>I have applied this patch to kernel 4.4 and get the following result. </div><div><br></div><div>To delete a fully-mapped 10TB thin devices, </div><div>with this patch takes 48 sec.</div><div>without this patch takes 48 sec.</div><div><br></div><div>To read an empty thin device while deleting a fully-mapped 10TB thin devices,</div><div>with this patch I/O throughput drops from 4.6TB/s to 4.3TB/s </div><div>without this patch, I/O blocks.</div><div><br></div><div>To write an empty thin device while deleting a fully-mapped 10TB thin devices,</div><div>with this patch I/O throughput drops from 3.2TB/s to below 4MB/s</div><div>without this patch, I/O blocks</div><div><br></div><div>Since it looks like the write performance still suffer from the lock contention, I make it to sleep 100 msec between lock release and reacquire in commit_decs(). </div><div><br></div><div>To write an empty thin device while deleting a fully-mapped 10TB thin devices </div><div>With sleep in commit_decs(), I/O throughput drops from 3.2TB/s to 2.2TB/s, but the deletion time grows from 48sec to 2m54sec.</div><div><br></div><div>The one thing I am curious about is what data structures are dm-thin tries to protect by holding the pool lock during all those btree operations. At first, I think the lock is held to protect the btree itself. But based on the comments in the source code, I believe that it has already been protected by the read/writes lock in transaction manager (dm_tm_read/write_lock). Does this mean that the pool lock is held only to protect the reference count bitmap/btree?</div><div><br></div><div>Thanks,</div><div>Dennis</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-01-27 0:19 GMT+08:00 Joe Thornber <span dir="ltr"><<a href="mailto:thornber@redhat.com" target="_blank">thornber@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Dennis,<br>
<br>
This is indeed useful.  Is there any chance you could re-run your test<br>
with this patch applied please?<br>
<br>
<a href="https://github.com/jthornber/linux-2.6/commit/64197a3802320c7a7359ff4a3e592e2bc5bb73dc" rel="noreferrer" target="_blank">https://github.com/jthornber/linux-2.6/commit/64197a3802320c7a7359ff4a3e592e2bc5bb73dc</a><br>
<div class="HOEnZb"><div class="h5"><br>
- Joe<br>
<br>
--<br>
dm-devel mailing list<br>
<a href="mailto:dm-devel@redhat.com">dm-devel@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/dm-devel" rel="noreferrer" target="_blank">https://www.redhat.com/mailman/listinfo/dm-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif">Dennis Yang </span><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif"> </span><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif"><br>QNAP Systems, Inc.</span><div><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif">Skype: qnap.dennis.yang<br>Email:</span><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif"> <a href="mailto:dennisyang@qnap.com" target="_blank">dennisyang@qnap.com</a></span><div><span lang="EN-US" style="font-size:10pt;font-family:Arial,sans-serif">Tel:</span><span style="font-family:Arial,sans-serif;font-size:13.333333969116211px"> (+886)-2-2393-5152 ext. </span><span style="font-family:Arial,sans-serif;font-size:13.333333969116211px">15018</span><div><font face="Arial, sans-serif" size="2">Address: </font><span style="color:rgb(51,51,51);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:12px;line-height:18.66666603088379px">13F., No.56, Sec. 1, Xinsheng S. Rd., Zhongzheng Dist., Taipei City, Taiwan</span></div></div></div></div></div>
</div>