[Bug 248008] Post r358097 an i386 system can hang with many processes sleeping on btalloc

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248008

Rick Macklem <rmacklem at FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeff at FreeBSD.org,
                   |                            |kib at FreeBSD.org,
                   |                            |rlibby at freebsd.org

--- Comment #2 from Rick Macklem <rmacklem at FreeBSD.org> ---
Sorry, the comments got messed up. I guess I shouldn't have done the
attachment before submitting or something..

Anyhow, here is what has gone on.
Post r358097 (it took a while to bisect to this commit), running a kernel
build over NFS on an i386 system (I also got it once doing the build on
UFS), I've gotten hangs with many processes sleeping on "btalloc".

Ryan Libby made the following suggestions and I implemented #2, which
fixed the hangs.

   I think the patch is not complete.  It looks like the problem is that
   for systems that do not have UMA_MD_SMALL_ALLOC, we do
        uma_zone_set_allocf(vmem_bt_zone, vmem_bt_alloc);
   but we haven't set an appropriate free function.  This is probably why
   UMA_ZONE_NOFREE was originally there.  When NOFREE was removed, it was
   appropriate for systems with uma_small_alloc.

   So by default we get page_free as our free function.  That calls
   kmem_free, which calls vmem_free ... but we do our allocs with
   vmem_xalloc.  I'm not positive, but I think the problem is that in
   effect we vmem_xalloc -> vmem_free, not vmem_xfree.

   Three possible fixes:
    1: The one you tested, but this is not best for systems with
    uma_small_alloc.
    2: Pass UMA_ZONE_NOFREE conditional on UMA_MD_SMALL_ALLOC.
    3: Actually provide an appropriate vmem_bt_free function.

   I think we should just do option 2 with a comment, it's simple and it's
   what we used to do.  I'm not sure how much benefit we would see from
   option 3, but it's more work.

-- 
You are receiving this mail because:
You are the assignee for the bug.