Date: Tue, 28 Dec 2004 17:05:51 -0500 From: Bosko Milekic <bmilekic@technokratis.com> To: John Baldwin <jhb@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: panic: uma_zone_slab is looping Message-ID: <20041228220551.GA62320@technokratis.com> In-Reply-To: <200412281538.15251.jhb@FreeBSD.org> References: <20041209144233.GA46928@peter.osted.lan> <20041226225651.GA87178@peter.osted.lan> <20041227013745.GA5267@technokratis.com> <200412281538.15251.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Dec 28, 2004 at 03:38:15PM -0500, John Baldwin wrote: > This is what I wondered about earlier in the thread. The problem is that > recursion needs to be a per-allocation (or per-thread) state, not per-zone, > since a zone may be used by multiple threads at the same time. Is it really > desired behavior of the bucket zone that if two threads alloc at the same > time one gets NULL because it sees the other's use and thinks it is > recursing? Not really, but in the bucket zone case it is less of a problem because a failed bucket allocation will just result in a uma_zalloc_internal() from occuring, and the probability of the bucket allocation failing because of that uk_recurse being [bogusely] non-zero and forcing a failure is relatively small, in that it might not be worth the effort of further instrumenting. In theory, the uk_recurse per-keg/zone flag is supposed to protect from re-entry from the VM, but in practise this is only really possible (or should only be possible) with the bucket zone itself. We should not have any OFFPAGE allocations from below (VM) requiring separate slab headers. The uk_recurse flag is imperfect in that sometimes it'll tell you it thinks there is a recursion but when in fact there isn't. As long as the behavior is constrained to solely the bucket zone and the probability of occurance of the latter event is small (even if it does occur for the bucket zone, it is not fatal, like it could be for other zones), it shouldn't matter. -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041228220551.GA62320>