From owner-freebsd-current@FreeBSD.ORG Thu May 29 19:28:02 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 922FA6BC; Thu, 29 May 2014 19:28:02 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 326FF2EC9; Thu, 29 May 2014 19:28:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s4TJRvU0084205; Thu, 29 May 2014 22:27:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua s4TJRvU0084205 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.8/Submit) id s4TJRvDF084204; Thu, 29 May 2014 22:27:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 29 May 2014 22:27:57 +0300 From: Konstantin Belousov To: John Baldwin Subject: Re: Processor cores not properly detected/activated? Message-ID: <20140529192756.GI3991@kib.kiev.ua> References: <20140524014713.GF13462@carrick-users.bishnet.net> <201405291318.36130.jhb@freebsd.org> <201405291444.19497.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8/UBlNHSEJa6utmr" Content-Disposition: inline In-Reply-To: <201405291444.19497.jhb@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: freebsd-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 19:28:02 -0000 --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 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--