On 5/8/26 1:21 AM, ... wrote:
Hi,
Sorry for the late reply. I spent some time reworking the prototype
along the
lines suggested in the previous discussion, and also tried to make the
VDO-level measurements more explicit.
There were two main points in the previous feedback. The first was that IAA
support should not add IAA-specific branches in the VDO data path, such as:
if (iaa_enabled)
...
else
...
Instead, the VDO compression path should use the kernel asynchronous
compression API, so that IAA can be plugged in through the existing
crypto API
and the VDO code does not need to know about a specific accelerator. The
second point was that the benefit should be shown at the dm-vdo level,
because
raw compression-algorithm benchmarks do not necessarily translate into
user-visible VDO throughput or data-efficiency gains.
The attached patch is my current prototype for the first point. It
replaces the
direct LZ4 calls in the VDO compression path with a crypto acomp based
compression context. The prototype uses the configured crypto compression
algorithm for VDO compression and decompression, so the IAA path can be
reached
through deflate-iaa without adding IAA-specific checks in data-vio.c.
In the future please submit patches (even prototypes) according to the
official guidelines:
https://docs.kernel.org/process/submitting-patches.html. Patches sent as
attachments may get overlooked.
This is still an RFC prototype, not a final patch series. In particular,
I am
not trying to claim that this patch solves the full long-term metadata
problem
for mixing arbitrary compression algorithms in one VDO format. My immediate
goal is narrower: make the IAA implementation follow the generic async
compression API direction, and check whether that is an acceptable basis for
preparing a proper mergeable series.
In general, this approach looks reasonable. However, I do not think we
can separate this work from the larger concerns of supporting multiple
compression algorithms. From what I can see, IAA acceleration does not
support the LZ4 algorithm, only deflate. That means that adding IAA
support necessarily means having two different compression algorithms to
support. We cannot simply change the algorithm out from under volumes
that already have LZ4-compressed data.
The attached patch also contains a small amount of temporary
compression-statistics/debug code. I used it only to identify the VDO
compression entry point and report VDO-level input and payload sizes for the
comparison below. It is not required for the functional part of IAA support,
and I can drop it or keep it behind debug guards when splitting the work
into
reviewable patches.
For the VDO-level test, the data set was silesia.tar, a tar archive of the
files from the Silesia corpus. I did not configure the VDO thread counts, so
they used the default startup parameters. For this test I only enabled VDO
compression and disabled deduplication:
lvcreate --type vdo -n vdo_lv -L 180G -V 200G \
--compression=y --deduplication=n \
vdo_vg
I then created and mounted an ext4 filesystem on top of the VDO device, and
used dd on regular files in the mounted filesystem to measure read/write
throughput. The write test copied the Silesia tar archive into the mounted
filesystem:
dd if=../silesia_raw.tar of=./silesia.tar bs=1M oflag=direct
The read test read the same file back from the mounted ext4 filesystem:
dd if=./silesia.tar of=/dev/null bs=1M iflag=direct
After the write test, I queried the VDO compression statistics with:
dmsetup message vdo_vg-vpool0-vpool 0 compress-stats
The temporary compress-stats fields mean:
calls: number of VDO compression calls counted in this run
input_bytes: total bytes passed to the compressor by VDO
payload_bytes: total compressed payload bytes produced by the
compressor
saved_bytes: input_bytes - payload_bytes
ratio_x100: payload_bytes / input_bytes * 100, truncated to an integer
ratio: the same payload/input ratio printed as a decimal value
LZ4 result:
write:
202+1 records in
202+1 records out
211,957,760 bytes copied, 0.357554 s, 593 MB/s
read:
202+1 records in
202+1 records out
211,957,760 bytes copied, 0.183408 s, 1.2 GB/s
compress-stats:
calls 51626
input_bytes 211460096
payload_bytes 122705607
saved_bytes 88754489
ratio_x100 58
ratio 0.58x
IAA/deflate result:
write:
202+1 records in
202+1 records out
211,957,760 bytes copied, 0.228480 s, 928 MB/s
read:
202+1 records in
202+1 records out
211,957,760 bytes copied, 0.183265 s, 1.2 GB/s
compress-stats:
calls 51626
input_bytes 211460096
payload_bytes 107585987
saved_bytes 103874109
ratio_x100 50
ratio 0.50x
The two runs had the same number of compression calls and the same VDO
compression input size. On this 211.5 MB VDO compression input, IAA/deflate
stored about 107.6 MB of payload, while LZ4 stored about 122.7 MB. That is
about 15.1 MB less payload for IAA/deflate on this data set.
I have two concerns with this benchmark. First, you have disabled
deduplication here. However, for any normal dm-vdo volume, deduplication
should be on. The deduplication overhead should be part of the
comparison when measuring throughput. (Deduplication is the core feature
of dm-vdo. Any user who does not want the deduplication features is most
likely better off using a different storage target altogether.)
Second, what does the performance look like when the IAA hardware is not
present, or is disabled? It's worth making sure there is no performance
regression in that case.
The throughput result also looks more useful than my earlier report.
With the
default VDO thread settings, the write-side dd result improved from 593 MB/s
with LZ4 to 928 MB/s with IAA/deflate, while the read-side result stayed
essentially the same at about 1.2 GB/s. This matches the lower-level 4KB
compression tests I ran earlier: IAA showed higher compression bandwidth
than
LZ4 at that granularity, while its decompression bandwidth was not
better than
LZ4. So the VDO result is consistent with IAA helping the compressed
write path
more than the read/decompression path.
My question is whether this revised approach is a reasonable direction for
adding IAA support to dm-vdo: use the generic async compression API in
the VDO
compression path, avoid IAA-specific branches, and then split the prototype
into smaller reviewable patches. If this direction looks acceptable, I can
continue by removing or isolating the temporary statistics code,
improving the
benchmark description, and preparing a proper patch series.
The use of the async compression API here seems reasonable. We could
switch the existing LZ4 calls to do LZ4 through the regular crypto
interface. However, supporting deflate-iaa would need much more than
this, as previously mentioned.
There are also a few places where your patch does too much. For
instance, there is no need to add a module parameter for the algorithm,
since the algorithm cannot be changed yet. (When it is added, that
parameter should probably be set on the table line and not with a module
parameter anyway.)
Matt
Regards,
Ze Fu
原始邮件
------------------------------------------------------------------------
发件人：Matthew Sakai <[email protected]>
发件时间：2026年5月5日 01:03
收件人：Mikulas Patocka <[email protected]>
抄送：... <[email protected]>, dm-devel <[email protected]>
主题：Re: dm vdo: add optional Intel IAA-backed compression support
On 5/4/26 12:01 PM, Mikulas Patocka wrote:
>
>
> On Wed, 29 Apr 2026, Matthew Sakai wrote:
>
>>
>>
>> On 4/29/26 11:24 AM, Mikulas Patocka wrote:
>>> Hi
>>>
>>> I think the best way how to support it would be to modify the VDO target
>>> to use the asynchronous compression API (so that it could use arbitrary
>>> algorithms). Then, the support for IAA could be plugged in easily with
>>> little or no extra code.
>>
>> I agree that this is the right approach, but supporting arbitrary
compression
>> algorithms will require some significant changes on its own. dm-
vdo currently
>> has nowhere to store information about what algorithm is used for which
>> blocks, so it would require reworking the metadata. (We would probably store
>
> You can store the algorithm in the superblock and use it for all blocks on
> the device. This would be not as flexible as per-block algorithm
> specification, but it should be relatively easy to implement - and it
> would allow you to evaluate whether different algorithms improve
> performance or compression ratio.
We could do that, certainly. It means picking the compression algorithm
at format time, which also means no existing vdo volumes could take
advantage of it. But we'd still need an upgrade for existing volumes to
handle the new superblock field. I think managing the compression
algorithm per-block is not that much more work, especially since I've
already written much of it.
>> the extra compression information in the compression block header.) This
>> metadata rework in turn will require some effort to make sure we can
continue
>> to support existing users who will want to continue to use dm-
vdo volumes in
>> the current format.
>
> Mikulas
>
