On Fri, Jan 09 2015 at 8:59pm -0500,
Jens Axboe <axboe@xxxxxxxxx> wrote:
> On 01/09/2015 06:48 PM, Mike Snitzer wrote:
> >
> >A third "make install" resulted in:
> >
> >[ 543.711782] __bt_get: values before for loop: last_tag=114, index=3
> >[ 543.713411] __bt_get: values after for loop: last_tag=96, index=3
> >[ 543.714495] bt_get: __bt_get() returned -1
> >[ 543.715222] queue_num=0, nr_tags=128, reserved_tags=0, bits_per_word=5
> >[ 543.716351] nr_free=128, nr_reserved=0
> >[ 543.717016] active_queues=0
> >
> >(things definitely do seem better, e.g. less frequent failure and no
> >longer see the last_tag=127 case)
>
> So if we end up freeing in batches, it's not totally unlikely that
> the case could hit where all were busy, and they got freed in
> between. Does seem a bit peculiar, though. The dump above, is that
> for the first failure case of invoking __bt_get()? I don't see the:
>
> _still_ returned -1
>
> which would seem to back up the theory, though. So I think this
> might actually be good, even if you hit that case.
Right, I'm not seeing the double failure case ("_still_ returned -1")
but I did see it in the previous 3 patches, albeit infrequently.
> Bart, could you try the patch (the -v4) and your DM hang and see if
> it solves it for you?
Yes, I'm interested to hear from Bart on v4 too.
> >>If this one doesn't solve it, I'll reproduce it myself to save the
> >>ping-pong effort :-)
> >
> >I don't mind testing it since it is really quick. But OK.
>
> OK, then we can stick to that. Let me know if you hit the case of it
> both the initial -1 and the following -1, since that would indicate
> it's not fixed.
Will do.
Thanks for all your help.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
