Re: [PATCH] MAXCPU alterable in kernel config - needs testers

On 10/8/06, LI Xin <delphij_at_delphij.net> wrote:
> 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?
>

Perhaps the way to handle this, then, is to only allow it to be set lower.

--- Harrison