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.
-Mark 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. > -- > This messages posted from opensolaris.org > _______________________________________________ > zfs-code mailing list > zfs-code at opensolaris.org > http://opensolaris.org/mailman/listinfo/zfs-code
