On 2022-03-17 Jia Tan wrote:
> I attached two patches to this message. The first should fix a bug
> with the timeouts.
Thanks! This and the deadlock are now fixed (I committed them a few days
ago).
> The second patch is for the memlimit_threading update. I added a new
> API function that will
> > As promised, I have attached a patch to solve the problem. Instead of
> > doing as I had originally proposed, I simply added a wake up signal
> > to a sleeping thread if partial updates are enabled. When the worker
> > wakes up, it checks if no more input
> > is available and signals to the
On 2022-03-15 Jia Tan wrote:
> As promised, I have attached a patch to solve the problem. Instead of
> doing as I had originally proposed, I simply added a wake up signal
> to a sleeping thread if partial updates are enabled. When the worker
> wakes up, it checks if no more input
> is available
Hello!
Once again, sorry for the delay. I will be busy the rest of the week. I
will get back to xz early next week.
On 2022-03-07 Sebastian Andrzej Siewior wrote:
> 32 cores:
>
> | $ time ./src/xz/xz -tv tars.tar.xz -T0
> | tars.tar.xz (1/1)
> | 100 % 2.276,2 MiB / 18,2 GiB = 0,122 1,6
> I tested this locally by setting the timeout for xz to 0 on line 57 of
> src/xz/coder.c and it deadlocks on a truncated xz file. It seems like a
> race condition because it deadlocks ~90% of the time in my liblzma tests.
> When debugging, I can see that the main thread does not return from
>
> > > This:
> > >
> > > diff --git a/src/liblzma/common/stream_decoder_mt.c
> > > b/src/liblzma/common/stream_decoder_mt.c
> > > --- a/src/liblzma/common/stream_decoder_mt.c
> > > +++ b/src/liblzma/common/stream_decoder_mt.c
> > > @@ -786,7 +786,7 @@ read_output_and_wait(struct lzma_stream_coder
On 2022-03-11 21:59:19 [+0800], Jia Tan wrote:
> > This:
> >
> > diff --git a/src/liblzma/common/stream_decoder_mt.c
> > b/src/liblzma/common/stream_decoder_mt.c
> > --- a/src/liblzma/common/stream_decoder_mt.c
> > +++ b/src/liblzma/common/stream_decoder_mt.c
> > @@ -786,7 +786,7 @@
> This:
>
> diff --git a/src/liblzma/common/stream_decoder_mt.c
> b/src/liblzma/common/stream_decoder_mt.c
> --- a/src/liblzma/common/stream_decoder_mt.c
> +++ b/src/liblzma/common/stream_decoder_mt.c
> @@ -786,7 +786,7 @@ read_output_and_wait(struct lzma_stream_coder *coder,
>
On 2022-03-10 22:16:27 [+0800], Jia Tan wrote:
> I started writing tests in the new framework and I found one bug and
> one issue. If you want to check out the tests I have so far, here is a
> link to check out my progress:
>
> > Testing is welcome. It would be nice if someone who has 12-24 hardware
> > threads could test if it scales well. One needs a file with like a
> > hundred blocks, so with the default xz -6 that means a 2.5 gigabyte
> > uncompressed file, smaller if one uses, for example, --block-size=8MiB
> >
On 2022-03-07 01:08:40 [+0200], Lasse Collin wrote:
> Hello!
Hi,
> I committed something. The liblzma part shouldn't need any big changes,
> I hope. There are a few FIXMEs but some of them might actually be fine
> as is. The xz side is just an initial commit, there isn't even
>
Hello!
I committed something. The liblzma part shouldn't need any big changes,
I hope. There are a few FIXMEs but some of them might actually be fine
as is. The xz side is just an initial commit, there isn't even
--memlimit-threading option yet (I will add it).
Testing is welcome. It would be
On 2022-02-07 01:46:32 [+0200], Lasse Collin wrote:
> I now plan to use memlimit_threading and memlimit_stop in the lzma_mt
> structure. Documentation is still needed but hopefully those are a bit
> more obvious.
oki
…
[ long update ]
> I added support for lzma_get_progress(). It is needed to
On 2021-12-31 Sebastian Andrzej Siewior wrote:
> On 2021-12-15 23:33:58 [+0200], Lasse Collin wrote:
> > Yes. It's fairly simple from implementation point of view but is it
> > clear enough for the users, I'm not sure.
> >
> > I suppose the alternative is having just one limit value and a flag
>
On 2021-12-15 23:33:58 [+0200], Lasse Collin wrote:
> Yes. It's fairly simple from implementation point of view but is it
> clear enough for the users, I'm not sure.
>
> I suppose the alternative is having just one limit value and a flag to
> tell if it is a soft limit (so no limit for
On 2021-12-04 Sebastian Andrzej Siewior wrote:
> On 2021-11-30 00:25:11 [+0200], Lasse Collin wrote:
> > Separate soft and hard limits might be convenient from
> > implementation point of view though. xz would need --memlimit-soft
> > (or some better name) which would always have some default
On 2021-11-30 00:25:11 [+0200], Lasse Collin wrote:
> Hello!
Hello,
> On 2021-02-05 Sebastian Andrzej Siewior wrote:
> > - Added enum `lzma_memlimit_opt' to lzma_stream_decoder_mt() as an
> > init parameter. The idea is to specify how to obey the memory limit
> > so the user can keep using
Hello!
On 2021-02-05 Sebastian Andrzej Siewior wrote:
> - Added enum `lzma_memlimit_opt' to lzma_stream_decoder_mt() as an
> init parameter. The idea is to specify how to obey the memory limit
> so the user can keep using one API and not worry to fail due to the
> memory limit. Lets assume
On 2021-07-20 02:09:31 [+0200], Guillem Jover wrote:
> Hi!
Hi Guillem,
> On Fri, 2021-02-05 at 00:11:57 +0100, Sebastian Andrzej Siewior wrote:
> > From: Sebastian Andrzej Siewior
>
> I've only skimmer very quickly over the patch, but I've been running
> it on my system in addition to a locally
Hello!
On 2021-07-20 Guillem Jover wrote:
> I've only skimmer very quickly over the patch, but I've been running
> it on my system in addition to a locally modified dpkg that uses this
> new support, and it seems to be working great. :)
Great to hear, thanks! :-) Unfortunately I don't have any
Hi!
On Fri, 2021-02-05 at 00:11:57 +0100, Sebastian Andrzej Siewior wrote:
> From: Sebastian Andrzej Siewior
I've only skimmer very quickly over the patch, but I've been running
it on my system in addition to a locally modified dpkg that uses this
new support, and it seems to be working great.
21 matches
Mail list logo
