Remove mklocale which is not needed anymore

Add localedef(1), a locale definition generator tool

The localedef tool can read entire (and unmodified) CLDR posix definition
files, and generate all 6 LC categories: LC_COLLATE, LC_CTYPE, LC_TIME,

Add localedef(1), a locale definition generator tool

The localedef tool can read entire (and unmodified) CLDR posix definition
files, and generate all 6 LC categories: LC_COLLATE, LC_CTYPE, LC_TIME,
LC_NUMERIC, LC_MONETARY and LC_MESSAGES.

This tool has a long history with Solaris. The Nexenta developers
modified it to read CLDR files and created the much richer collation
formats. The libc collation functions have to be modified to read the
new format (called "BSD-1.0") and to handle the new data structures.

The result will be that locale-sensitive tools and functions will now
properly sort multibyte and unicode strings.

Obtained from: Dragonfly

show more ...

Merge ^/head r285793 through r285923.

Replace GNU RCS ident with a BSD license ident

Rationale: ident(1) is useful out of RCS, lot of scripts are using ident(1) and
failing when base is built WITHOUT_RCS.

This version is:
- fully compa

Replace GNU RCS ident with a BSD license ident

Rationale: ident(1) is useful out of RCS, lot of scripts are using ident(1) and
failing when base is built WITHOUT_RCS.

This version is:
- fully compatible with RCS 5.7 ident.
- fully compatible with RCS 5.9 ident.
- passes all ident test from GNU RCS 5.9 test suite

This version has support for: svn extension for the Keyword id (double colon and
# before last $)

Différences with GNU RCS ident:
- no long options as found in GNU RCS 5.9 (but not commented there).
- '-V' reports nothing but has been added for compatibility.

Differential Revision: https://reviews.freebsd.org/D3200
Reviewed by: pfg

show more ...

Merge ^/head r285341 through r285792.

Add an initial NUMA affinity/policy configuration for threads and processes.

This is based on work done by jeff@ and jhb@, as well as the numa.diff
patch that has been circulating when someone asks

Add an initial NUMA affinity/policy configuration for threads and processes.

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

show more ...

Catch up with HEAD (r280229-r284686).

Merge ^/head r284188 through r284643.

Merge from head @274131

Remove old fmake. It wasn't built by default for some time. Users that
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

Remove old fmake. It wasn't built by default for some time. Users that
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

show more ...

Merge from head

Merge ^/head r283771 through r283870.

Switch to mandoc's version of makewhatis(8), whatis(1), apropos(1) utilities.

This change among other things improve search capabilities over the manpages
allowing fine grain query.

A new build opt

Switch to mandoc's version of makewhatis(8), whatis(1), apropos(1) utilities.

This change among other things improve search capabilities over the manpages
allowing fine grain query.

A new build option WITHOUT_MANDOCDB has been added to keep the ancient version
of the database and the tools. The plan is to entirely remove this option before
11.0-RELEASE.

Differential Revision: https://reviews.freebsd.org/D2603

show more ...

MFH: r282615-r283655

Sponsored by: The FreeBSD Foundation

Merge sync of head

Remove demandoc(1) from the build

MFH: r282315-r282534

Sponsored by: The FreeBSD Foundation

Merge from head

Replace groff's soelim by soeliminate(1) renamed soelim(1)

MFH: r281855-r282312

Sponsored by: The FreeBSD Foundation

Add ELF Tool Chain's c++filt to the build

Differential Revision: https://reviews.freebsd.org/D2408
Reviewed by: brooks, imp
Sponsored by: The FreeBSD Foundation

MFH: r280643-r281852

Sponsored by: The FreeBSD Foundation

Disable truss, gprof, and lint on arm64, they don't build.

Sponsored by: The FreeBSD Foundation

Merge from HEAD

Switch to ELF toolchain readelf(1)

ELF toolchain readelf lacked some functionality at the time other tools
(like size, strip, nm, etc.) were switched over to the ELF toolchain
versions. That has bee

Switch to ELF toolchain readelf(1)

ELF toolchain readelf lacked some functionality at the time other tools
(like size, strip, nm, etc.) were switched over to the ELF toolchain
versions. That has been addressed as of the last update, so we can add
it to the list.

PR: 198950 [exp-run]
Reviewed by: bapt, imp, rpaulo
Relnotes: yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D2156

show more ...