Few days ago I upgraded my system firmware, upgraded
base to r327991 and altered snooping to
cluster-on-die. Its hard to say what is making
the server feels like a completely system due
to all these changes (also running llvm 6.0),
but I am betting it is the NUMA optimizations.
It is so responsive! Thanks for the amazing
On Sat, Jan 13, 2018 at 7:39 PM, Jeff Roberson <jrober...@jroberson.net>
> This work has been committed. It is governed by a new 'NUMA' config
> option and 'DEVICE_NUMA' and 'VM_NUMA_ALLOC' have both been retired. This
> option is fairly light weight and I will likely enable it in GENERIC before
> 12.0 release.
> I have heard reports that switching from a default policy of first-touch
> to round-robin has caused some performance regression. You can change the
> default policy at runtime by doing the following:
> cpuset -s 1 -n first-touch:all
> This is the default set that all others inherit from. You can query the
> current default with:
> cpuset -g -s 1
> I will be investigating the regression and tweaking the default policy
> based on performance feedback from multiple workloads. This may take some
> numactl is still functional but deprecated. Man pages will be updated
> Thank you for your patience as I work on refining this somewhat involved
> On Tue, 9 Jan 2018, Jeff Roberson wrote:
> Hello folks,
>> I am working on merging improved NUMA support with policy implemented by
>> cpuset(2) over the next week. This work has been supported by Dell/EMC's
>> Isilon product division and Netflix. You can see some discussion of these
>> changes here:
>> The work has been done in user/jeff/numa if you want to look at svn
>> history or experiment with the branch. It has been tested by Peter Holm on
>> i386 and amd64 and it has been verified to work on arm at various points.
>> We are working towards compatibility with libnuma and linux mbind. These
>> commits will bring in improved support for NUMA in the kernel. There are
>> new domain specific allocation functions available to kernel for UMA,
>> malloc, kmem_, and vm_page*. busdmamem consumers will automatically be
>> placed in the correct domain, bringing automatic improvements to some
>> device performance.
>> cpuset will be able to constrains processes, groups of processes, jails,
>> etc. to subsets of the system memory domains, just as it can with sets of
>> cpus. It can set default policy for any of the above. Threads can use
>> cpusets to set policy that specifies a subset of their visible domains.
>> Available policies are first-touch (local in linux terms), round-robin
>> (similar to linux interleave), and preferred. For now, the default is
>> round-robin. You can achieve a fixed domain policy by using round-robin
>> with a bitmask of a single domain. As the scheduler and VM become more
>> sophisticated we may switch the default to first-touch as linux does.
>> Currently these features are enabled with VM_NUMA_ALLOC and MAXMEMDOM.
>> It will eventually be NUMA/MAXMEMDOM to match SMP/MAXCPU. The current NUMA
>> syscalls and VM_NUMA_ALLOC code was 'experimental' and will be deprecated.
>> numactl will continue to be supported although cpuset should be preferred
>> going forward as it supports the full feature set of the new API.
>> Thank you for your patience as I deal with the inevitable fallout of such
>> sweeping changes. If you do have bugs, please file them in bugzilla, or
>> reach out to me directly. I don't always have time to catch up on all of
>> my mailing list mail and regretfully things slip through the cracks when
>> they are not addressed directly to me.
> firstname.lastname@example.org mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
email@example.com mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"