Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 6 Jul 2018 14:32:19 -0700
From:      John Baldwin <jhb@FreeBSD.org>
To:        Matt Macy <mmacy@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: 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
Message-ID:  <2c818e79-bcce-670c-9521-c4d171c3f5b1@FreeBSD.org>
In-Reply-To: <201807060206.w662636M035282@repo.freebsd.org>
References:  <201807060206.w662636M035282@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2c818e79-bcce-670c-9521-c4d171c3f5b1>