Re: Processor cores not properly detected/activated?

--8/UBlNHSEJa6utmr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 29, 2014 at 02:44:19PM -0400, John Baldwin wrote:
> On Thursday, May 29, 2014 2:24:45 pm Adrian Chadd wrote:
> > On 29 May 2014 10:18, John Baldwin <[e-mail]> wrote:
> >=20
> > >> > It costs wired memory to increase it for the kernel.  The userland=
 set size
> > >> > can be increased rather arbitrarily, so we don't need to make it b=
ut so large
> > >> > as it is easy to bump later (even with a branch).
> > >>
> > >> Well, what about making the API/KBI use cpuset_t pointers for things
> > >> rather than including it as a bitmask? Do you think there'd be a
> > >> noticable performance overhead for the bits where it's indirecting
> > >> through a pointer to get to the bitmask data?
> > >
> > > The wired memory is not due to cpuset_t.  The wired memory usage is d=
ue to things
> > > that do 'struct foo foo_bits[MAXCPU]'.  The KBI issues I mentioned ab=
ove are
> > > 'struct rmlock' (so now you want any rmlock users to malloc space, or=
 you
> > > want rmlock_init() call malloc?  (that seems like a bad idea)).  The =
other one
> > > is smp_rendezvous.  Plus, it's not just a pointer, you really need a =
(pointer,
> > > size_t) tuple similar to what cpuset_getaffinity(), etc. use.
> >=20
> > Why would calling malloc be a problem? Except for the initial setup of
> > things, anything dynamically allocating structs with embedded things
> > like rmlocks are already dynamically allocating them via malloc or
> > uma.
> >=20
> > There's a larger fundamental problem with malloc, fragmentation and
> > getting the required larger allocations for things. But even a 4096
> > CPU box would require a 512 byte malloc. That shouldn't be that hard
> > to do. It'd just be from some memory that isn't close to the rest of
> > the lock state.
>=20
> Other similar APIs like mtx_init() don't call malloc(), so it would be
> unusual behavior.  However, we have several other problems before we can
> move beyond 256 anyway (like pf).

What is pf ?

We definitely have a problem with the legacy APIC mode, we must start
using x2APIC, I believe.

--8/UBlNHSEJa6utmr
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (FreeBSD)

iQIcBAEBAgAGBQJTh4o8AAoJEJDCuSvBvK1BeMMP/iP/0DILCdd2alpNB5JqX3Zv
neGeWXSB20sOBVqBSzNNdlFT9FZuYCB9bd+UWY1NZyh2b9xrMKV2wbGa616B+ih5
zFknmwyvj5lmAf0EhDcUmcOo+Cc7EBH+2bgO0ODIbyCcNQpK4Ic/Atl3Kk9Vi1uV
ZryNmtd9NR0nxDtwBZDgzK0yr4hs96NlSCXTMGPoatZmGG1h2xVnLvJ2qeOO8x4F
+RAyvsnJ0xJKumMfcyP37aXgxrMrQNT3ZQmxAw7apSuEM7wIrzbUPztNbrp7/Sih
rP8onIevJr+xlCtODfFeJrW1cOF+13IngC2krIcWFxS2ctiAQEbH81M1OO2+Ep0r
kffTQ5+VizFNi5t/AJ3orDfs3ielJQyo+tHsCSgV9bPgsXLZKxTzdcaj0+0FO5lF
joqbGi7jLPfORxHZYs09qr8GVII4eUvuVjt/UGtXGMubs1is0TiQaGWtew/4UsGw
d8+rTYvs2+FCb5yL3oOXUUIBjH32ieH9P4JEZDp1SwviMXguO2OV8+TmERwWeIWu
TVvWdAtYnaqgyE7c906jqV6ARgC7VkCCf7Agv/CutPKDZNKv+fpqgSeo5i6+baLE
d0LlzERPP3jVYRTcGHgYFF75UbBkfyz4ZbrdP00AarzXoNJcKYbdpstmv7VOvYJQ
U4z0WIGKdaa3Ht1ZA7Gy
=evye
-----END PGP SIGNATURE-----

--8/UBlNHSEJa6utmr--