On Fri, May 18, 2007 at 08:22:26AM -0600, Mark Maybee wrote:
> Yup, J?rgen is correct.  The problem here is that we are blocked in
> arc_data_buf_alloc() while holding a hash_lock.  This is bug 6457639.
> One possibility, for this specific bug might be to drop the lock before
> the allocate and then redo the read lookup (in case there is a race)
> with the necessary buffer already in hand.

Any updates on this? We don't see those deadlocks when ZIL is disabled
and we're thinking about disabling ZIL by default for 7.0-RELEASE if we
won't find fix for this. It is somehow quite easy to triggers for some
workloads.

> J?rgen Keil wrote:
> >>Kris Kennaway <kris at FreeBSD.org> found a deadlock,
> >>which I think is not FreeBSD-specific.
> >>
> >>When we are running low in memory and kmem_alloc(KM_SLEEP) is called,
> >>the thread waits for the memory to be reclaimed, right?
> >
> >>In such situation the arc_reclaim_thread thread is woken up.
> >>
> >>Ok. I've two threads waiting for the memory to be freed:
> >>
> >>First one, and this one is not really problematic:
> >...
> >>And second one, which holds
> >>arc_buf_t->b_hdr->hash_lock:
> >
> >
> >Bug 6457639 might be related, 
> >http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6457639
> >
> >In this case I also found the arc deadlocking because of KM_SLEEP
> >allocations, while having parts of the buf hash table locked.

-- 
Pawel Jakub Dawidek                       http://www.wheel.pl
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: 
<http://mail.opensolaris.org/pipermail/zfs-code/attachments/20070809/3d801944/attachment.bin>

Reply via email to