> Okay, so that is what you are tracking. I remember that there was a > stall in the decoding but I don't remember how it played out. > > I do remember that I had something for memory allocation/ limit but I > don't remember if we settled on something or if discussion is needed. > Also how many decoding threads make sense, etc.
We ended up changing xz to use (total_ram / 4) as the default "soft limit". If the soft limit is reached, xz will decode single threaded. The "hard limit" shares the same environment variable and xz option (--memlimit-decompress). > > - New ARM64 filter needs to be properly coordinated to other xz > > implementations and documented. > > - Converting tests to the new tuktest framework. Most of the tests > > have been written, but they still need to be reviewed. > > - liblzma and xz functionality to convert a string into a filter > > chain. A draft of this is on the mailing list already, but the syntax > > needs finalizing and the code was not polished. > > - A patch for .lz support needs review. > > - A patch for crc64 optimizations needs review. > > This reminds me that I once posted a patch to use openssl for the > sha256. > https://www.mail-archive.com/xz-devel@tukaani.org/msg00429.html > > Some distro is using sha256 instead crc64 by default, I don't remember > which one… Not that I care personally ;) I am unsure if we will have time to include your sha256 patch, but if we finish all the tasks with extra time it may be considered. > > - Misc. minor bug fixes. > > > > This is everything currently planned. Most things are done and just > > needs review and minor improvements. Don't worry, multi threaded > > decompression will be coming to xz in a stable release very soon! > > Okay. That is good to hear. I would like to get it in Debian and have > dpkg support for the upcomming stable release. The earlier the better > since this affects quite a large part of the system. The toolchain > freeze is in January and I think that dpkg is part of it (or people will > probably get very nervous if such a change gets integrated later in the > cycle). Thank you for notifying us about the January freeze. I hope this is the extra bit of motivation needed for us to release 5.4.0 as soon as it is ready. Lasse is confident that we will have the release by December. I will see what we can do to make it as early December as possible since I understand not wanting to make large changes just before a freeze. The interface for liblzma and xz for the multi threaded decoder does not have any planned changes, so things could probably be developed and tested using 5.3.3. This would actually help us because having people test and give us feedback on both performance and the interface would help before committing to things in the stable release. Thanks again Sebastian for your contributions to both xz and Debian's use of xz! Jia Tan
