Erik Jan Tromp wrote:
The troublesome test files compressed without error, but at a cost of time on some machines (lesser thread count).
Thanks. I chose a conservative 2 GiB limit to avoid problems with signed addresses, but I have been reading again the linux configuration help, and it states that when HIGHMEM is enabled, the per process memory limit is 3 GiB.
As I guess that all 32 bit machines with enough processors will have HIGHMEM (or similar) enabled, maybe you could try to raise the limit to 3 GiB replacing '0x7FFFFFFF' with '0xBFFFFFFFLL' in the patch and see what happens? Thanks.
Side note: the system default value is unchanged between unpatched& patched.
Yes. The system default is the number of processors reported by sysconf.
I'm curious as to the disparity between system default& actual threads. Dispatcher(s)& workers?
Exactly. As you can see in the plzip manual[1], "For each input file, a splitter thread and several worker threads are created, acting the main thread as muxer (multiplexer) thread."
[1] http://www.nongnu.org/lzip/manual/plzip_manual.html#Program-design Best regards, Antonio. _______________________________________________ Lzip-bug mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lzip-bug
