Benchmarking dm-crypt with different block size, request number and scheduler
Hi
As you asked to run benchmarks with more requests and bigger block size to
test if sorting inside dm-crypt is needed. Here are the results.
Conclusion: if I increase the number of requests to 1000000, the cfq
scheduler behaves nondeterministically, the same workload on the raw
device (without crypt) takes sometimes 15 seconds and sometimes 34
seconds. Cfq scheduler was likely not designed to run with such high
request count.
Even with the number of requests increased to 1000000 and block size
increased to 4096, dm-crypt still benefits from sorting writes
(performance is 3 times better when sorting requests in dm-crypt).
The deadline scheduler behaves much more deterministically than cfq,
increasing the number of requests to 1000000 generally fixes the problems
and makes sorting in dm-crypt not needed. With 100000 requests and 4096
block size, sorting in dm-crypt still improves performance, but only a
little (17 seconds without sorting, 14 with sorting).
Mikulas
Data:
raw device: benchmark on raw device without crypt
dm-crypt-without-sorting: dm crypt without request sorting.
dm-crypt-offload-writes-to-thread: dm crypt with all write requests
submitted to a thread. No sorting of requests is done.
dm-crypt-retain-write-ordering: dm crypt with write requests being
submitted in the same order they were received in.
dm-crypt-sort-writes: dm crypt with write requests being sorted using
red-black tree.
cfq scheduler, blocksize 512, 1000000 requests:
raw device: 0m15.087s-0m34.446s (the result varies and seems to depend on
previous workload)
dm-crypt-without-sorting: 0m49.316s
dm-crypt-offload-writes-to-thread: 0m22.118s
dm-crypt-retain-write-ordering: 0m21.939s
dm-crypt-sort-writes: 0m21.451s
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
02-20-2012, 08:22 PM
Mikulas Patocka
Benchmarking dm-crypt with different block size, request number and scheduler
On Mon, 20 Feb 2012, Alasdair G Kergon wrote:
> Were these tests all using that 'worst case' alignment you mentioned?
> - If so, people with such alignment could be advised to use deadline with
> huge queue depth?
>
> Alasdair
Some tests are with 512-byte block size, other with 4096-byte block size.
Alignment of partition start doesn't matter, because they were done on a
SCSI disk with 512-byte hardware sector size. Only alignment of partition
size does matter (if the partition has odd number of sectors, the kernel
uses 512-byte block size for this partition).
Mikulas
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
Benchmarking dm-crypt with different block size, request number and scheduler
