Sorry Pawel, we have not done much with this bug. It is not a high priority bug for us, since we don't see it under Solaris, and there have been lots of other demands on our time and resources lately. Have you tried exploring the fix I suggested? We are always happy to accept fixes from the community :-).
-Mark Pawel Jakub Dawidek wrote: > 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. > > > ------------------------------------------------------------------------ > > _______________________________________________ > zfs-code mailing list > zfs-code at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-code
