Date: Tue, 28 Sep 2010 15:06:35 -0400 From: John Baldwin <jhb@freebsd.org> To: sbruno@freebsd.org Cc: "freebsd-current@FreeBSD.org" <freebsd-current@freebsd.org>, Robert Watson <rwatson@freebsd.org>, Joshua Neal <jdneal@gmail.com> Subject: Re: MAXCPU preparations Message-ID: <201009281506.35960.jhb@freebsd.org> In-Reply-To: <1285699244.2454.63.camel@home-yahoo> References: <1285601161.7245.7.camel@home-yahoo> <201009281429.30747.jhb@freebsd.org> <1285699244.2454.63.camel@home-yahoo>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, September 28, 2010 2:40:44 pm Sean Bruno wrote: > On Tue, 2010-09-28 at 13:29 -0500, John Baldwin wrote: > > On Tuesday, September 28, 2010 12:45:11 pm Sean Bruno wrote: > > > On Tue, 2010-09-28 at 02:48 -0500, Robert Watson wrote: > > > > On Mon, 27 Sep 2010, Joshua Neal wrote: > > > > > > > > > I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's already > > > > > asking the kernel for the max number and throwing an error if it doesn't > > > > > agree: > > > > > > > > Yes, it looks like MAXCPU was bumped in the kernel without bumping the limit > > > > in libmemstat. The bug could be in not having a comment by the definition of > > > > MAXCPU saying that MEMSTAT_MAXCPU needs to be modified as well. > > > > > > > > > I was thinking a more future-proof fix would be to get rid of the static > > > > > allocations and allocate the library's internal structures based on the > > > > > value of kern.smp.maxcpus. > > > > > > > > Agreed. I'm fairly preoccupied currently, but would be happy to accept > > > > patches :-). > > > > > > > > Robert > > > > > > Working on a dynamic version today. I'll spam it over to you for review > > > later. > > > > > > I'm moving the percpu struct definitions outside of struct memory_type, > > > allocating quantity kern.smp.maxcpus, removing the boundary checks based > > > on MEMSTAT_MAXCPU and then removing MEMSTAT_MAXCPU all together. > > > > If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus. > > > > I assume that mp_maxid is the new kern.smp.maxcpus? Can you inject some > history here so I can understand why one is "better" than the other? mp_maxid is the variable in the kernel of the maximum possible CPU ID in the running kernel. It is what all kernel code uses for dynamically sized per-CPU arrays such as UMA. It can be smaller than MAXCPU if the platform does not support hotplug CPUs (true for all of our current platforms). maxcpus was only added to export the value of MAXCPU so that user code that uses libkvm to read kernel memory directly can work with datastructures that use statically sized arrays (foo[MAXCPU]) rather than dynamically sized arrays. Aside from that one specific use case, maxcpus should not be used. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201009281506.35960.jhb>