This is based on work done by jeff@ and jhb@, as well as the numa.diff
patch that has been circulating when someone asks for first-touch NUMA
on -10 or -11.
* Introduce a simple set of VM policy and iterator types.
* tie the policy types into the vm_phys path for now, mirroring how
the initial first-touch allocation work was enabled.
* add syscalls to control changing thread and process defaults.
* add a global NUMA VM domain policy.
* implement a simple cascade policy order - if a thread policy exists, use it;
if a process policy exists, use it; use the default policy.
* processes inherit policies from their parent processes, threads inherit
policies from their parent threads.
* add a simple tool (numactl) to query and modify default thread/process
policities.
* add documentation for the new syscalls, for numa and for numactl.
* re-enable first touch NUMA again by default, as now policies can be
set in a variety of methods.
This is only relevant for very specific workloads.
This doesn't pretend to be a final NUMA solution.
The previous defaults in -HEAD (with MAXMEMDOM set) can be achieved by
'sysctl vm.default_policy=rr'.
This is only relevant if MAXMEMDOM is set to something other than 1.
Ie, if you're using GENERIC or a modified kernel with non-NUMA, then
this is a glorified no-op for you.
Thank you to Norse Corp for giving me access to rather large
(for FreeBSD!) NUMA machines in order to develop and verify this.
Thank you to Dell for providing me with dual socket sandybridge
and westmere v3 hardware to do NUMA development with.
Thank you to Scott Long at Netflix for providing me with access
to the two-socket, four-domain haswell v3 hardware.
Thank you to Peter Holm for running the stress testing suite
against the NUMA branch during various stages of development!
Tested:
* MIPS (regression testing; non-NUMA)
* i386 (regression testing; non-NUMA GENERIC)
* amd64 (regression testing; non-NUMA GENERIC)
* westmere, 2 socket (thankyou norse!)
* sandy bridge, 2 socket (thankyou dell!)
* ivy bridge, 2 socket (thankyou norse!)
* westmere-EX, 4 socket / 1TB RAM (thankyou norse!)
* haswell, 2 socket (thankyou norse!)
* haswell v3, 2 socket (thankyou dell)
* haswell v3, 2x18 core (thankyou scott long / netflix!)
* Peter Holm ran a stress test suite on this work and found one
issue, but has not been able to verify it (it doesn't look NUMA
related, and he only saw it once over many testing runs.)
* I've tested bhyve instances running in fixed NUMA domains and cpusets;
all seems to work correctly.
Verified:
* intel-pcm - pcm-numa.x and pcm-memory.x, whilst selecting different
NUMA policies for processes under test.
Review:
This was reviewed through phabricator (https://reviews.freebsd.org/D2559)
as well as privately and via emails to freebsd-arch@. The git history
with specific attributes is available at https://github.com/erikarn/freebsd/
in the NUMA branch (https://github.com/erikarn/freebsd/compare/local/adrian_numa_policy).
This has been reviewed by a number of people (stas, rpaulo, kib, ngie,
wblock) but not achieved a clear consensus. My hope is that with further
exposure and testing more functionality can be implemented and evaluated.
Notes:
* The VM doesn't handle unbalanced domains very well, and if you have an overly
unbalanced memory setup whilst under high memory pressure, VM page allocation
may fail leading to a kernel panic. This was a problem in the past, but it's
much more easily triggered now with these tools.
* This work only controls the path through vm_phys; it doesn't yet strongly/predictably
affect contigmalloc, KVA placement, UMA, etc. So, driver placement of memory
isn't really guaranteed in any way. That's next on my plate.
Sponsored by: Norse Corp, Inc.; Dell
for a long time, quota(1) utility supported only PF_INET.
- Clean up confusing changes in f_mntfromname.
- Add an entry for rquotad with rpc/udp6 to inetd.conf.
PR: 194084
Update setkey and libipsec to understand aes-gcm-16 as an
encryption method.
A partial commit of the work in review D2936.
Submitted by: eri
Reviewed by: jmg
MFC after: 2 weeks
Sponsored by: Rubicon Communications (Netgate)
This hack is very fragile, and was broken on powerpc64 when metamode was
introduced. Removing it survives a buildworld for all architectures, and
fixes the build on powerpc64.
Fault in the buffer prior to writing to workaround poor performance due
to interaction with kernel fs deadlock avoidance code. See the comment
prior to vn_io_fault_doio() in sys/kern/vfs_vnops.c for details of the
issue.
On my stable/10 desktop with a 16MB obj.o and "ar r out.a obj.o" I see
the following run times (seconds):
x ar.r284891
+ ar.patched
+----------------------------------------------------------------------+
|+ |
|+ x|
|+ xx|
|A |A|
+----------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 3 1.307 1.321 1.315 1.3143333 0.0070237692
+ 3 0.020 0.023 0.022 0.021666667 0.0015275252
Difference at 95.0% confidence
-1.29267 +/- 0.0115203
-98.3515% +/- 0.876513%
(Student's t, pooled s = 0.00508265)
Thanks to kib for diagnosing and explaining the issue and suggesting
the workaround.
Reviewed by: eadler, kib
MFC after: 1 week
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2933
The code path to support units conversions from the command line
need not initialize neither libedit nor the history. Therefore, only do
that when in interactive mode.
This hides the issue reported in PR bin/201167 whereby running commands
of the form 'echo "$(units ft in)"' would corrupt the terminal. The real
issue causing the corruption most likely still remains somewhere.
PR: bin/201167
Differential Revision: D2935
Reviewed by: eadler
When requesting install(1) to only make relative symlinks, by pass all the
done to actually compute the relative symlink if the path given in argument is
already a relative path
The image is not accepted for provisioning otherwise. Bump the
VHD creator tool version and the version of mkimg to signify our
success in provisioning.
Note that this also imapcts the dynamic VHD images.
Tested by: gjb@
of megabytes. This is on top of having the image rounded to the
matching geometry of the image size.
By rounding up to the next MB after rounding to the geometry, we
lost idempotency. Subsequent calls to resize the image will keep
increasing the image size.
Tested by: gjb@
really need it can find it in the devel/fmake port or pkg install fmake.
Note: This commit is orthogonal to the question 'can we fmake buildworld'.
Differential Revision: https://reviews.freebsd.org/D2840
address is loopback. So it is shown if both are not loopback.
The man page says that it is shown if the local or foreign
address is not loopback. Change the man page to reflect the
code.
MFC after: 3 days
Off by default, build behaves normally.
WITH_META_MODE we get auto objdir creation, the ability to
start build from anywhere in the tree.
Still need to add real targets under targets/ to build packages.
Differential Revision: D2796
Reviewed by: brooks imp
multiple of the cylinder size. This is what qemu-img seems to
be doing. Make sure to handle boundary cases where increasing
the image size by 1 cyclinder's worth would also result in a
change of geometry.
