https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254333
Richard Scheffenegger <rsch...@freebsd.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsch...@freebsd.org
--- Comment #4 from Richard Scheffenegger <rsch...@freebsd.org> ---
I just noticed, that sysctl will actually do a syscall to sysctl twice.
First, with no buffer space - expecting to receive the size to allocate for a
buffer, then it tries to allocate twice as much buffer (apparently "for
reasons"), before doing the syscall to sysctl a 2nd time.
As the system continues to run, I am curious how large the list of hostcache
entries is just prior to the "freeze" (of sysctl), and if the system may be
space-constrained.
Note that during the call, it appears that both kernel and userspace need
memory (twice as much in the userspace). userspace seems to use a non-blocking
malloc call, after the first round where the return length is checked.
Possibly the system has a hard time allocating a sufficiently large chunk of
memory, if the hostcache is fully utilized and extremely busy...
In sbuf_new, the kernel is trying a malloc(size, M_SBUF, M_WAITOK|M_ZERO)...
Perhaps the sysctl callback procedure could be improved to
a) not actually allocate memory when the user has not yet provided a buffer to
fill - only return the require size (reducing the chances to run out-of-space
somewhat)
b) not allocate a huge chunk in sbuf_new right away, but use sbuf_extend
repeatedly (although sbuf.c will actually grab a larger chunk of memory, copy
the data over,and release the old chunk - thus driving temporary memory
requirements higher
c) use a different memory model supporting disjoint segments of a c-string
scattered in smaller memory chunks, subsequently concatenating them on the
SYSCTL_OUT.
d) change the M_WAITOK in /kern/subr_sbuf.c#59 to M_NOWAIT and expect an error
on very busy systems every once in a while.
As a reasonable short term fix, I guess a combination of M_NOWAIT in sbuf.c and
use of sbuf_new(smaller size) / sbuf_extend(smaller_size) may be the prudent
approach, if this turns out to be the culprit.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
