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>
