Date: Wed, 31 Aug 2011 12:18:42 -0700 From: Sean Bruno <seanbru@yahoo-inc.com> To: Ivan Voras <ivoras@freebsd.org> Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: Large machine test ideas Message-ID: <1314818323.2610.6.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: <j3ju8s$kuo$2@dough.gmane.org> References: <j38lj5$s9a$1@dough.gmane.org> <CAMBSHm_Sv_KZUs4h-tDGAZCq8s2qo_bMmfZxLbVkcH1=_Wu0OQ@mail.gmail.com> <CAF-QHFW=aU3=iKE9WMg6%2BD6eP9OXth=c0AidBc140ykmAPD2zg@mail.gmail.com> <201108291415.32605.jhb@freebsd.org> <j3ju8s$kuo$2@dough.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2011-08-30 at 17:11 -0700, Ivan Voras wrote: > On 29.8.2011. 20:15, John Baldwin wrote: > > > However, the SRAT code just ignores the table when it encounters an issue like > > this, it doesn't hang. Something else later in the boot must have hung. > > Anyway... that machine can in its maximal configuration be populated > with eight 10-core CPUs, i.e. 80 physical / 160 logical, so here's a > vote from me to bump the shiny new cpuset infrastructure maximum CPU > count to 256 before 9.0. > > http://www.supermicro.com/products/system/5U/5086/SYS-5086B-TRF.cfm Doesn't that (MAXCPU) seriously impact VM usage, lock contention etc ... ? I mean, if we have 2 cpus in a machine, but MAXCPU is set to 256, there is a bunch of "lost" memory and higher levels of lock contention? I thought that attilio was taking a stab at enhancing this, but at the current time anything more than a value of 64 for MAXCPU is kind of a "caveat emptor" area of FreeBSD. Sean P.S. I say 64 as yahoo has been running 64 cpus with local patches for a while, so I know that this works fairly well.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1314818323.2610.6.camel>