Date: Thu, 29 May 2014 22:27:57 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-current <freebsd-current@freebsd.org> Subject: Re: Processor cores not properly detected/activated? Message-ID: <20140529192756.GI3991@kib.kiev.ua> In-Reply-To: <201405291444.19497.jhb@freebsd.org> References: <20140524014713.GF13462@carrick-users.bishnet.net> <201405291318.36130.jhb@freebsd.org> <CAJ-VmonQOafnYB=xhUZnkU0c_qFVw8ZFSRkAbnpA%2B3NV8qt2ww@mail.gmail.com> <201405291444.19497.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <jhb@freebsd.org> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140529192756.GI3991>