Date: Sun, 7 May 2023 16:24:52 -0600 From: Warner Losh <imp@bsdimp.com> To: Moin Rahman <bofh@freebsd.org> Cc: Ed Maste <emaste@freebsd.org>, freebsd-arch <freebsd-arch@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Support for more than 256 CPU cores Message-ID: <CANCZdfpVvG28wWp7nYmuQPwCaS2DcwzidkM4VOoZq12OCD5M4Q@mail.gmail.com> In-Reply-To: <E6E2D507-A9F0-4199-8501-3D9B901C5831@freebsd.org> References: <CAPyFy2DODJVhs5o8xddaj7GD8zZfC3g1zm_guWKeCmeE07wn-w@mail.gmail.com> <E6E2D507-A9F0-4199-8501-3D9B901C5831@freebsd.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On Sun, May 7, 2023, 3:51 PM Moin Rahman <bofh@freebsd.org> wrote: > > > > On May 5, 2023, at 3:38 PM, Ed Maste <emaste@freebsd.org> wrote: > > > > FreeBSD supports up to 256 CPU cores in the default kernel configuration > > (on Tier-1 architectures). Systems with more than 256 cores are > > available now, and will become increasingly common over FreeBSD 14’s > > lifetime. The FreeBSD Foundation is supporting the effort to increase > > MAXCPU, and PR269572[1] is open to track tasks and changes. > > > > As a project we have scalability work ahead of us to make best use of > > high core count machines, but at a minimum we should be able to boot a > > GENERIC kernel on such systems, and have an ABI for the FreeBSD 14 > > release that supports such a configuration. > > > > Some changes have already been committed in support of increased MAXCPU, > > including increasing MAX_APIC_ID (commit c8113dad7ed4) and a number of > > changes to reduce bloat (such as commits 42f722e721cd, e72f7ed43eef, > > 78cfa762ebf2 and 74ac712f72cf). > > > > The next step is to increase the maximum cpuset size for userland. > > I have this change open in review D39941[2] and an exp-run request in > > PR271213[3]. Following that the kernel change for increasing MAXCPU is > > in D36838[4]. > > > > Additional work on bloat reduction will continue after this change, and > > looking forward FreeBSD is going to need ongoing effort from the > > community and the FreeBSD Foundation to continue improving scalability. > > > > [1] https://bugs.freebsd.org/269572 > > [2] https://reviews.freebsd.org/D39941 > > [3] https://bugs.freebsd.org/271213 > > [4] https://reviews.freebsd.org/D36838 > > > > By any chance will this be merged into 13? > Nope. It breaks too many kernel KBIs that are exposed to at least some modules. Warner > > Kind regards, > Moin > [-- Attachment #2 --] <div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, May 7, 2023, 3:51 PM Moin Rahman <<a href="mailto:bofh@freebsd.org">bofh@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> <br> > On May 5, 2023, at 3:38 PM, Ed Maste <<a href="mailto:emaste@freebsd.org" target="_blank" rel="noreferrer">emaste@freebsd.org</a>> wrote:<br> > <br> > FreeBSD supports up to 256 CPU cores in the default kernel configuration<br> > (on Tier-1 architectures). Systems with more than 256 cores are<br> > available now, and will become increasingly common over FreeBSD 14’s<br> > lifetime. The FreeBSD Foundation is supporting the effort to increase<br> > MAXCPU, and PR269572[1] is open to track tasks and changes.<br> > <br> > As a project we have scalability work ahead of us to make best use of<br> > high core count machines, but at a minimum we should be able to boot a<br> > GENERIC kernel on such systems, and have an ABI for the FreeBSD 14<br> > release that supports such a configuration.<br> > <br> > Some changes have already been committed in support of increased MAXCPU,<br> > including increasing MAX_APIC_ID (commit c8113dad7ed4) and a number of<br> > changes to reduce bloat (such as commits 42f722e721cd, e72f7ed43eef,<br> > 78cfa762ebf2 and 74ac712f72cf).<br> > <br> > The next step is to increase the maximum cpuset size for userland.<br> > I have this change open in review D39941[2] and an exp-run request in<br> > PR271213[3]. Following that the kernel change for increasing MAXCPU is<br> > in D36838[4].<br> > <br> > Additional work on bloat reduction will continue after this change, and<br> > looking forward FreeBSD is going to need ongoing effort from the<br> > community and the FreeBSD Foundation to continue improving scalability.<br> > <br> > [1] <a href="https://bugs.freebsd.org/269572" rel="noreferrer noreferrer" target="_blank">https://bugs.freebsd.org/269572</a><br>; > [2] <a href="https://reviews.freebsd.org/D39941" rel="noreferrer noreferrer" target="_blank">https://reviews.freebsd.org/D39941</a><br>; > [3] <a href="https://bugs.freebsd.org/271213" rel="noreferrer noreferrer" target="_blank">https://bugs.freebsd.org/271213</a><br>; > [4] <a href="https://reviews.freebsd.org/D36838" rel="noreferrer noreferrer" target="_blank">https://reviews.freebsd.org/D36838</a><br>; > <br> <br> By any chance will this be merged into 13?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Nope. It breaks too many kernel KBIs that are exposed to at least some modules.</div><div dir="auto"><br></div><div dir="auto">Warner</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> Kind regards,<br> Moin<br> </blockquote></div></div></div>help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpVvG28wWp7nYmuQPwCaS2DcwzidkM4VOoZq12OCD5M4Q>