From owner-freebsd-current@FreeBSD.ORG Fri Aug 8 05:28:13 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ABFD0AD1 for ; Fri, 8 Aug 2014 05:28:13 +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 4E36F2B17 for ; Fri, 8 Aug 2014 05:28:13 +0000 (UTC) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s785S7F2077591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Aug 2014 08:28:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s785S7F2077591 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s785S7ET077590; Fri, 8 Aug 2014 08:28:07 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Aug 2014 08:28:07 +0300 From: Konstantin Belousov To: "Ivan A. Kosarev" Subject: Re: libthr and main thread stack size Message-ID: <20140808052807.GB93733@kib.kiev.ua> References: <53E36E84.4060806@ivan-labs.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rvoHLDQQ7oYmoXsQ" Content-Disposition: inline In-Reply-To: <53E36E84.4060806@ivan-labs.com> 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@freebsd.org 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: Fri, 08 Aug 2014 05:28:13 -0000 --rvoHLDQQ7oYmoXsQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 07, 2014 at 04:18:12PM +0400, Ivan A. Kosarev wrote: > Hello, >=20 > According to libthr's thr_init.c (the 9.2 version) init_main_thread()=20 > allocates s.c. "red zone" below the main stack in order to protect other= =20 > stacks. The size of the main stack is determined by the=20 > _thr_stack_initial variable that is declared extern though it doesn't=20 > seem it can be changed. The value of the variable is set to 4M on 64-bit= =20 > platforms which is obviously not sufficient for the most of real programs. >=20 > Can anyone please confirm that there is no way to increase the stack=20 > size for the main thread and thus any program linked against libthr has= =20 > only a few megabytes of stack memory for its main thread--whatever the=20 > system stack size (ulimit -s) is set to? Yes, there is no way to change the main thread stack clamping. Could you provide a reasonable use case for the 4MB stack ? Anyway, I somewhat sympathize to the idea to stop clamping the main thread stack, and to not reuse it for other threads stack carving. This also means that non-main threads stack allocator should stop tracking the explicit location for the stacks and rely on vm mmap(2) base selection instead. I do not know the motivations why the current scheme of stacks allocation was chosen. The changes do not look too involved. --rvoHLDQQ7oYmoXsQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJT5F/nAAoJEJDCuSvBvK1B/28QAJ9sY74XKbI2LPGp0uycKSzX 0sztit6Ni/UhrX9YF1AdPI/4DYPcV6cuJIUqWrPMrQzhYeJLbC5qz2KvKiY8TsNB 4SsHoIRQlFSo36PQDp5xZwMoMnRhAigsRHMHN3B4vn1N7vggzTsCFo+Nym77ALlz Ui0rprqQKBmzUVxPBKX4RCs8+fcyETUI4oz49WI2M4afWN3W+psVyU8Okl7RIu8W N2V3gIE6aQPrpYESURzCxdxu0gZb9jXl2v1sR0L85pYgrjUuFr9vE646rbazpWzI UxxhQRLXTwEGcHvYku7aMUDePGDPOZp5zyt08ShHfAB6QTPSAxv0/jL0aoWg+7mf b51KhCyAyu3BFkA+1QO63X/40gtALL94a/aB3xH70XQdsTMtfTj9jkfNesfiD4kz nqRBxGv3khChfaTT+/Pv1y/o9G5ukaFwtAkG+sD11uJpY2n+rF+IydzoWEILmJ2X vhENZ+GdkCaPRnXxvjeEB2jJJgM4uOCp1w96ZAzbOwiUWaRMQhzcP2ZavEyS/Aiv UmI3BH8CSrt2a9Vspn8/UV+L+YbNghsmVKbwelQtKJd7gtFSSmI0m5dc5k0Cwois EFIjy3bMoBBV67lQ1RFHVzYqHFKAOV4+7u78EEawF9ZDoMAFWjBCX7zzOtES1opd ioBz1ROAnvFbTXyU0hBw =ZTfK -----END PGP SIGNATURE----- --rvoHLDQQ7oYmoXsQ--