Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 03 Mar 2021 18:44:02 +0000
From:      bugzilla-noreply@freebsd.org
To:        bugs@FreeBSD.org
Subject:   [Bug 253992] ufsdirhash_build() sleeps with directory vnode locked due to M_WAITOK
Message-ID:  <bug-253992-227-dS83hqag0k@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-253992-227@https.bugs.freebsd.org/bugzilla/>
References:  <bug-253992-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=3D253992

--- Comment #2 from dgmorris@earthlink.net <dgmorris@earthlink.net> ---
Actually, we don't default to RR.

>From an email with Mark Johnston (and looking over the code paths):
> More to the point, I believe the zones are marked as FirstTouch because
> they pass "0" as the flags argument to uma_zcreate() -- and the
> keg_ctor() ends up setting the keg flags based on:
>
> 	/*
> 	 * Use a first-touch NUMA policy for kegs that pmap_extract() will
> 	 * work on.  Use round-robin for everything else.
> 	 *
> 	 * Zones may override the default by specifying either.
> 	 */
> #ifdef NUMA
> 	if ((keg->uk_flags &
> 	    (UMA_ZONE_ROUNDROBIN | UMA_ZFLAG_CACHE | UMA_ZONE_NOTPAGE)) =3D=3D 0)
> 		keg->uk_flags |=3D UMA_ZONE_FIRSTTOUCH;
> 	else if ((keg->uk_flags & UMA_ZONE_FIRSTTOUCH) =3D=3D 0)
> 		keg->uk_flags |=3D UMA_ZONE_ROUNDROBIN;
> #endif
>
> Then the zone flags inherit from the keg flags and there we are.

Yes, FIRSTTOUCH is the default policy for regular zones.

-- End email snippet --

And yes, sorry -- didn't realize I had an isi* function still in there. Yes,
this is Isilon. I tried to stay general about things.

Waiting on a domain specific scan in this case (again, because of First Tou=
ch)
may help -- but there may not be much the scan can do. In this case, there =
was
a separate kernel memory leak that had most of the domain tied up as "in us=
e",
obviating the ability for the pagedaemon to free pages for the domain, but =
one
can speculate a spike in load localized within one domain that provides a
similar situation for long enough for the directory lock waiters to be noti=
ced.

--=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-253992-227-dS83hqag0k>