From owner-cvs-src@FreeBSD.ORG Mon Feb 14 05:53:12 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D75F016A4CE; Mon, 14 Feb 2005 05:53:12 +0000 (GMT) Received: from creme-brulee.marcuscom.com (creme-brulee.marcuscom.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6266F43D4C; Mon, 14 Feb 2005 05:53:12 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from shumai.marcuscom.com (shumai.marcuscom.com [192.168.1.4]) j1E5rUjn080816; Mon, 14 Feb 2005 00:53:30 -0500 (EST) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Sam Leffler In-Reply-To: <42102C54.4000408@errno.com> References: <200502131838.j1DIc6tZ020690@repoman.freebsd.org> <1108337583.93267.1.camel@shumai.marcuscom.com> <20050214020531.GD40468@funkthat.com> <1108352249.93267.20.camel@shumai.marcuscom.com> <20050214040349.GA61763@elvis.mu.org> <1108355421.93267.23.camel@shumai.marcuscom.com> <42102C54.4000408@errno.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-xF3xy6mG0DvvNMPBDCex" Organization: MarcusCom, Inc. Date: Mon, 14 Feb 2005 00:52:41 -0500 Message-Id: <1108360361.93267.26.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port cc: John-Mark Gurney cc: src-committers@FreeBSD.org cc: Maxime Henrion cc: cvs-src@FreeBSD.org cc: cvs-all@FreeBSD.org cc: Daniel Eischen Subject: Re: cvs commit: src/lib/libpthread/thread thr_attr_init.c thr_init.c thr_private.h thr_stack.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2005 05:53:13 -0000 --=-xF3xy6mG0DvvNMPBDCex Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2005-02-13 at 20:43 -0800, Sam Leffler wrote: > Joe Marcus Clarke wrote: > > On Mon, 2005-02-14 at 05:03 +0100, Maxime Henrion wrote: > >=20 > >>Joe Marcus Clarke wrote: > >> > >>>On Sun, 2005-02-13 at 18:05 -0800, John-Mark Gurney wrote: > >>> > >>>>Joe Marcus Clarke wrote this message on Sun, Feb 13, 2005 at 18:33 -0= 500: > >>>> > >>>>>And there was much rejoicing! I would like to reiterate mezz's requ= est > >>>>>for a __FreeBSD_version bump once all the thread libraries are updat= ed. > >>>>>It would also be good to get this MFC'd before 5.4. Thanks again. > >>>> > >>>>If any application that cares/requires changes from the default, eith= er > >>>>due to large number of threads (requiring small stack size), or large > >>>>stacks, should already be patched with their new defaults... So > >>>>requiring a modification based upon version before/after this change > >>>>should be unnecessary... > >>> > >>>But knowing when this patch is implemented means we can _not_ patch > >>>certain applications. The best example of this is gstreamer. Gstream= er > >>>is patched to lower its initial thread stack usage to 1 MB since that > >>>was the previous limit. This severely limits gstreamer. With the > >>>larger initial thread stack size (something that is not changeable by > >>>individual applications), we no longer need to cripple gstreamer on > >>>-CURRENT. Therefore, I ask __FreeBSD_version to be bumped so I know > >>>when it's safe to let gstreamer take a full 2 MB of stack on the initi= al > >>>thread. > >> > >>Is there anything wrong with pthread_attr_setstacksize()? Using this t= o > >>patch the said applications would allow them to get an acceptably sized > >>stack whether the host is running an old or a recent version of > >>libpthread. It would also make sense to then submit the patches to the > >>vendor so that it's not too much a burden to maintain. > >=20 > >=20 > > This works for all threads but the initial thread. Gstreamer uses this > > thread for most of its operations. That stack size was set to be 1 MB > > when gstreamer really wanted 2. For all other thread problems, yes, I > > used pthread_attr_setstacksize() as the solution. >=20 > Sounds like this should be a tunable in the kernel if you it's really=20 > needed early on. I'm not familiar with the thread support but glancing=20 > at the diffs make it looks like the compile-time define was mostly=20 > eliminated so now it's just a question of finding a good place to get a=20 > starting value. Looks like the compile-time options are still there, it's just now dependent on sizeof(void *). In any event, even if kernel tunables are added, we need some way of knowing when that is from a userland (i.e. ports) perspective, hence my request for a __FreeBSD_version bump when the stacksize transition is complete. Joe >=20 > Sam >=20 >=20 >=20 --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-xF3xy6mG0DvvNMPBDCex Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCEDypb2iPiv4Uz4cRAsilAJ9zGI51USJyW9l5+ZvNfybbBBI9ZwCfdJ7v DG60BDAlQV5iMMPSIZBO5LY= =g3nP -----END PGP SIGNATURE----- --=-xF3xy6mG0DvvNMPBDCex--