Astrodog wrote: > On 10/8/06, David Xu <davidxu_at_freebsd.org> wrote: >> On Sunday 08 October 2006 19:23, Astrodog wrote: >> > With the quad core processors coming out soon, this is going to become >> > more of an issue.. (Sun T1/2000s aside). This is basically the same >> > patch from a few months ago, with updated offsets. >> > >> > If you don't define MAXCPU in the kernel config, it reverts to old >> > behavior. It has no logic to keep you from shooting yourself in the >> > foot though.. you can define options SMP and options MAXCPU 128 on >> > arm. >> > >> > --- Harrison Grundy >> >> I think MAXCPU should not be great than 32, since we currently define >> cpumask_t as an integer which now should be changed to a bitmap and >> a group of operations like we did for sigset_t. >> >> David Xu >> > > Currently, MAXCPU is 16 on most platforms. In general, this value serves as a boundary of the kernel logic, and is determined by various factors, e.g., the bits available in cpumask_t, etc., therefore, I really do not see much benefit of letting this value customizable. Perhaps we can say that the problem is not that the value itself is immutable by the system administrator, but it was (perhaps?) not correctly reflected the actual support that the kernel can provide? Cheers, -- Xin LI <delphij_at_delphij.net> http://www.delphij.net/ FreeBSD - The Power to Serve!
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:01 UTC