]> git.ipfire.org Git - thirdparty/xz.git/commit
xz: Limit --memlimit-compress to at most 4020 MiB for 32-bit xz.
authorLasse Collin <lasse.collin@tukaani.org>
Sat, 1 Feb 2020 17:56:18 +0000 (19:56 +0200)
committerLasse Collin <lasse.collin@tukaani.org>
Sat, 1 Feb 2020 17:56:18 +0000 (19:56 +0200)
commit353970510895f6a80adfe60cf71b70a95adfa8bc
tree112c8b4601bb0a90243cc7c7d4a6ad3433751e30
parentba76d67585f88677af9f48b48e7bdc3bb7687def
xz: Limit --memlimit-compress to at most 4020 MiB for 32-bit xz.

See the code comment for reasoning. It's far from perfect but
hopefully good enough for certain cases while hopefully doing
nothing bad in other situations.

At presets -5 ... -9, 4020 MiB vs. 4096 MiB makes no difference
on how xz scales down the number of threads.

The limit has to be a few MiB below 4096 MiB because otherwise
things like "xz --lzma2=dict=500MiB" won't scale down the dict
size enough and xz cannot allocate enough memory. With
"ulimit -v $((4096 * 1024))" on x86-64, the limit in xz had
to be no more than 4085 MiB. Some safety margin is good though.

This is hack but it should be useful when running 32-bit xz on
a 64-bit kernel that gives full 4 GiB address space to xz.
Hopefully this is enough to solve this:

https://bugzilla.redhat.com/show_bug.cgi?id=1196786

FreeBSD has a patch that limits the result in tuklib_physmem()
to SIZE_MAX on 32-bit systems. While I think it's not the way
to do it, the results on --memlimit-compress have been good. This
commit should achieve practically identical results for compression
while leaving decompression and tuklib_physmem() and thus
lzma_physmem() unaffected.
src/xz/hardware.c
src/xz/xz.1