Date: Wed, 6 Jul 2016 16:49:26 +0100 From: Andrew Turner <andrew@fubar.geek.nz> To: Nathan Whitehorn <nwhitehorn@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Review request: sparse CPU ID maps Message-ID: <20160706164926.7c3d116c@zapp> In-Reply-To: <5345fb94-91b8-5019-037e-d4825a694cfd@freebsd.org> References: <57761101.3030101@freebsd.org> <CAD9=5Xw-MmVVSSo6nRvSRvGaLbd1Z1YRyVKyF9JfmucNKMGBZg@mail.gmail.com> <5345fb94-91b8-5019-037e-d4825a694cfd@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2 Jul 2016 17:08:54 -0700 Nathan Whitehorn <nwhitehorn@freebsd.org> wrote: > A reasonable first pass at checking for this kind of bug is doing > grep -lR '< mp_ncpus'. Running that on sys/arm and sys/arm64 shows > the following files: > arm/mv/armadaxp/armadaxp_mp.c > arm/include/counter.h > arm/broadcom/bcm2835/bcm2836.c > arm/broadcom/bcm2835/bcm2836_mp.c > arm/freescale/imx/imx6_mp.c > arm/allwinner/aw_mp.c > arm/rockchip/rk30xx_mp.c > arm/amlogic/aml8726/aml8726_mp.c > arm/samsung/exynos/exynos5_mp.c > arm/arm/mp_machdep.c > arm/nvidia/tegra124/tegra124_mp.c I'm planning forcing people to clean up the arm code in 12. I can add this to the list of things that need to be fixed. > arm64/include/counter.h > arm64/arm64/gic_v3.c > arm64/arm64/gic_v3_its.c > arm64/arm64/gicv3_its.c I'll look at these in a few days when the code freeze is lifted. > > All of them should, in some sense, be CPU_FOREACH(), but it may not > matter. For example, it may not be possible to have sparse CPU IDs on > some or all of those SOCs. At least the generic ones (counter, > mp_machdep.c, gic (why are there both gic_v3_its.c and gicv3_its.c?)) > should be changed, I think. On arm it depends on the SoC. As far as I know no arm SoCs support sparse CPU IDs as they assign the ID based on the internal ID and, on a single cluster of CPUS, this seems to be contiguous. To boot on all CPUs on a multi-cluster SoC (e.g. big.LITTLE) we would need to rework the assignment of cpuids. As such I would expect us to keep a contiguous space. The place I would expect us to get a non-contiguous range on arm is if we grew support to offline CPUs. I think this will be needed on a few SoCs if we wish to run on many of the mobile chips. This may be needed for thermal and power reasons as many are only able to run for a short length of time before thermal throttling. On arm64 I'm planning on reworking the cpuid allocation code such that we may get sparse values, however I don't expect to have time for this in the next few months. Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160706164926.7c3d116c>