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@xxxxxxxxxx>:
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
Dennis Yang
QNAP Systems, Inc.
QNAP Systems, Inc.
Skype: qnap.dennis.yang
Email: dennisyang@xxxxxxxx
Email: dennisyang@xxxxxxxx
Tel: (+886)-2-2393-5152 ext. 15018
Address: 13F., No.56, Sec. 1, Xinsheng S. Rd., Zhongzheng Dist., Taipei City, Taiwan
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
