[dm-devel] I/O block when removing thin device on the same pool

[Dennis Yang]

Hi Joe,

I have applied this patch to kernel 4.4 and get the following result.

To delete a fully-mapped 10TB thin devices,
with this patch takes 48 sec.
without this patch takes 48 sec.

To read an empty thin device while deleting a fully-mapped 10TB thin
devices,
with this patch I/O throughput drops from 4.6TB/s to 4.3TB/s
without this patch, I/O blocks.

To write an empty thin device while deleting a fully-mapped 10TB thin
devices,
with this patch I/O throughput drops from 3.2TB/s to below 4MB/s
without this patch, I/O blocks

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().

To write an empty thin device while deleting a fully-mapped 10TB thin
devices
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.

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?

Thanks,
Dennis

2016-01-27 0:19 GMT+08:00 Joe Thornber <thornber at redhat.com>:

> Hi Dennis,
>
> This is indeed useful.  Is there any chance you could re-run your test
> with this patch applied please?
>
>
> https://github.com/jthornber/linux-2.6/commit/64197a3802320c7a7359ff4a3e592e2bc5bb73dc
>
> - Joe
>
> --
> dm-devel mailing list
> dm-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
>



-- 
Dennis Yang
QNAP Systems, Inc.
Skype: qnap.dennis.yang
Email: dennisyang at qnap.com
Tel: (+886)-2-2393-5152 ext. 15018
Address: 13F., No.56, Sec. 1, Xinsheng S. Rd., Zhongzheng Dist., Taipei
City, Taiwan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20160127/54ec93e9/attachment.htm>