diff options
| author | Gao Xiang <[email protected]> | 2019-06-24 15:22:56 +0800 |
|---|---|---|
| committer | Greg Kroah-Hartman <[email protected]> | 2019-06-26 09:44:40 +0800 |
| commit | 0ffd71bcc3a03ebb3551661a36052488369c4de9 (patch) | |
| tree | 8c75db866178919fcac405c5415ff4b505af793a /tools/perf/scripts/python/bin/stackcollapse-report | |
| parent | 7fc45dbc938a2e69ecd6a78a3c0074aa6c11fac9 (diff) | |
staging: erofs: introduce LZ4 decompression inplace
compressed data will be usually loaded into last pages of
the extent (the last page for 4k) for in-place decompression
(more specifically, in-place IO), as ilustration below,
start of compressed logical extent
| end of this logical extent
| |
______v___________________________v________
... | page 6 | page 7 | page 8 | page 9 | ...
|__________|__________|__________|__________|
. ^ . ^
. |compressed|
. | data |
. . .
|< dstsize >|<margin>|
oend iend
op ip
Therefore, it's possible to do decompression inplace (thus no
memcpy at all) if the margin is sufficient and safe enough [1],
and it can be implemented only for fixed-size output compression
compared with fixed-size input compression.
No memcpy for most of in-place IO (about 99% of enwik9) after
decompression inplace is implemented and sequential read will
be improved of course (see the following patches for test results).
[1] https://github.com/lz4/lz4/commit/b17f578a919b7e6b078cede2d52be29dd48c8e8c
https://github.com/lz4/lz4/commit/5997e139f53169fa3a1c1b4418d2452a90b01602
Reviewed-by: Chao Yu <[email protected]>
Signed-off-by: Gao Xiang <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Diffstat (limited to 'tools/perf/scripts/python/bin/stackcollapse-report')
0 files changed, 0 insertions, 0 deletions