svn commit: r336020 - in head/sys: amd64/include arm/include arm64/include i386/include kern mips/include powerpc/include riscv/include sparc64/include sys vm x86/acpica

[John Baldwin]

On 7/5/18 7:06 PM, Matt Macy wrote:
> Author: mmacy
> Date: Fri Jul  6 02:06:03 2018
> New Revision: 336020
> URL: https://svnweb.freebsd.org/changeset/base/336020
> 
> Log:
>   Back pcpu zone with domain correct pages
>   
>   - Change pcpu zone consumers to use a stride size of PAGE_SIZE.
>     (defined as UMA_PCPU_ALLOC_SIZE to make future identification easier)
>   
>   - Allocate page from the correct domain for a given cpu.
>   
>   - Don't initialize pc_domain to non-zero value if NUMA is not defined
>     There are some misconceptions surrounding this field. It is the
>     _VM_ NUMA domain and should only ever correspond to valid domain
>     values as understood by the VM.
>   
>   The former slab size of sizeof(struct pcpu) was somewhat arbitrary.
>   The new value is PAGE_SIZE because that's the smallest granularity
>   which the VM can allocate a slab for a given domain. If you have
>   fewer than PAGE_SIZE/8 counters on your system there will be some
>   memory wasted, but this is obviously something where you want the
>   cache line to be coming from the correct domain.
>   
>   Reviewed by: jeff
>   Sponsored by: Limelight Networks
>   Differential Revision:  https://reviews.freebsd.org/D15933

So one thing about this change that confused me abit is why any of srat.c
is being run at all in a non-NUMA kernel.  When we reworked the NUMA options
in HEAD to merge DEVICE_NUMA and VM_NUMA_ALLOC or whatever it was called
into a single NUMA, my impression is that srat.c should be 'optional numa'
in sys/conf/files.*.  Is it just oversight that that wasn't done earlier,
and should we in fact do that now?

-- 
John Baldwin