e6cfd293 jhb March 3, 2021, 10:46 p.m.
MFC after:	1 week
cgit
6241b571 wulf March 3, 2021, 10:43 p.m.
Submitted by:	Greg V <greg_AT_unrelenting_DOT_technology>
Reviewed by:	imp, wulf
MFC after:	1 week
Differential revision:	https://reviews.freebsd.org/D28995
cgit
49f6925c markj March 3, 2021, 10:34 p.m.
Maintain a cache of physically contiguous runs of pages for use as
output buffers when software encryption is configured and in-place
encryption is not possible.  This makes allocation and free cheaper
since in the common case we avoid touching the vm_page structures for
the buffer, and fewer calls into UMA are needed.  gallatin@ reports a
~10% absolute decrease in CPU usage with sendfile/KTLS on a Xeon after
this change.

It is possible that we will not be able to allocate these buffers if
physical memory is fragmented.  To avoid frequently calling into the
physical memory allocator in this scenario, rate-limit allocation
attempts after a failure.  In the failure case we fall back to the old
behaviour of allocating a page at a time.

N.B.: this scheme could be simplified, either by simply using malloc()
and looking up the PAs of the pages backing the buffer, or by falling
back to page by page allocation and creating a mapping in the cache
zone.  This requires some way to save a mapping of an M_EXTPG page array
in the mbuf, though.  m_data is not really appropriate.  The second
approach may be possible by saving the mapping in the plinks union of
the first vm_page structure of the array, but this would force a vm_page
access when freeing an mbuf.

Reviewed by:	gallatin, jhb
Tested by:	gallatin
Sponsored by:	Ampere Computing
Submitted by:	Klara, Inc.
Differential Revision:	https://reviews.freebsd.org/D28556
cgit
c113740f markj March 3, 2021, 10:01 p.m.
c49b0753 markj March 3, 2021, 10 p.m.
Reported by:	imp
cgit
afc3e54e mav March 3, 2021, 8:29 p.m.
It closes tiny race when the flag could be set between being cleared
and the space is checked, that would create us some more work.  The
flag setting is protected by both locks, so we can clear it in either
place, but in between both locks are dropped.

MFC after:	1 week
cgit
0c1a5eaa kevans March 3, 2021, 8:21 p.m.
Reported by:	pstef
Fixes:	55deb0a5f089 ("service(8): use an environment more [...]")
cgit
55deb0a5 kevans March 3, 2021, 6:25 p.m.
init(8) sets the "daemon" login class without specifying a pw
entry (so no substitutions are done on the variables). service(8)'s
use of env -L had the effect of specifying root's pw entry, with two
effects: getpwnam and getpwuid are being called, which may not be
entirely safe depending on what nsswitch is up to and what stage of
boot we are at, and substitutions would have been done.

Fix by teaching env(8) to allow -L -/classname to set the class
environment with no pw entry at all specified, and use it in
service(8).

PR:		253959
cgit
aff9b9ee mav March 3, 2021, 5:03 p.m.
I think it allowed to avoid some TX thread wakeups while the socket
buffer is full.  But add there another options if ic_check_send_space
is set, which means socket just reported that new space appeared, so
it may have sense to pull more data from ic_to_send for better TX
coalescing.

MFC after:	1 week
cgit
f2f24008 emaste March 3, 2021, 4:51 p.m.
Execute df(1) before and after the build (reporting in MiB for
consistency), and du(1) of /usr/obj.  Also include the uname.
cgit
29358694 crees March 3, 2021, 4:35 p.m.
Ranges use the function get_number, which means that ranges of names
are supported and indeed always have been, righ back to the initial
import.

PR:		docs/253969
Reported by:	Ben Bullock <benkasminbullock@gmail.com>
cgit
92fb29b9 noreply March 3, 2021, 4:28 p.m.
Avoid following the error path when the operation in fact succeeded.

Reviewed-by: Ryan Moeller <ryan@iXsystems.com>
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: James Wah <james@laird-wah.net>
Closes #11651
cgit
25352f9f crees March 3, 2021, 4:20 p.m.
PR:		docs/253975
cgit
e439ee83 noreply March 3, 2021, 4:15 p.m.
The spl_kmem_alloc showed up in some flamegraphs in a single-threaded
4k sync write workload at 85k IOPS on an
Intel(R) Xeon(R) Silver 4215 CPU @ 2.50GHz.
Certainly not a huge win but I believe the change is clean and
easy to maintain down the road.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Matthew Ahrens <mahrens@delphix.com>
Signed-off-by: Christian Schwarz <me@cschwarz.com>
Closes #11666
cgit
3242b535 noreply March 3, 2021, 4:14 p.m.
This value does work as expected, and is documented in the manpage.

Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Jake Howard <git@theorangeone.net>
Closes #11670
cgit