Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Aug 2020 17:14:38 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 248008] i386 system can hang with many processes sleeping on btalloc post base r358097
Message-ID:  <bug-248008-227-0jCGUAuHel@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-248008-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-248008-227@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D248008

Mark Johnston <markj@FreeBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markj@FreeBSD.org

--- Comment #5 from Mark Johnston <markj@FreeBSD.org> ---
I think the suggested patch is ok, but not for the reason stated.  On platf=
orms
without a direct map the problem is: to allocate btags we need a slab, and =
to
allocate a slab we need to map a page, and to map a page we need to allocate
btags.

We handle this recursion using a custom slab allocator which specifies
M_USE_RESERVE, allowing it to dip into a reserve of free btags.  Because the
returned slab can be used to keep the reserve populated, this ensures that
there are always enough free btags available to handle the recursion.

UMA_ZONE_NOFREE ensures that we never reclaim free slabs from the zone.=20
However, when it was removed, an apparent bug in UMA was exposed: keg_drain=
()
ignores the reservation set by uma_zone_reserve() in vmem_startup().  So un=
der
memory pressure we reclaim the free btags that are needed to break the
recursion.  That's why adding _NOFREE back fixes the problem: it disables t=
he
reclamation.

We could perhaps fix it more cleverly, by modifying keg_drain() to always l=
eave
uk_reserve slabs available.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-248008-227-0jCGUAuHel>