2011/8/31 Sean Bruno <[email protected]>: > 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.
With newest current you can redefine MAXCPU in your kernel config, so you don't need to bump the default value. I think 64 as default value is good enough. Removing MAXCPU dependency from the KBI is an important project someone should adopt and bring to conclusion. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[email protected]"
