From owner-cvs-all Mon Jul 5 17:45:58 1999 Delivered-To: cvs-all@freebsd.org Received: from sturm.canonware.com (canonware.com [204.107.140.54]) by hub.freebsd.org (Postfix) with ESMTP id EF80B14DF1; Mon, 5 Jul 1999 17:45:53 -0700 (PDT) (envelope-from jasone@canonware.com) Received: from localhost (jasone@localhost) by sturm.canonware.com (8.8.8/8.8.8) with ESMTP id RAA10680; Mon, 5 Jul 1999 17:44:02 -0700 (PDT) (envelope-from jasone@canonware.com) Date: Mon, 5 Jul 1999 17:44:02 -0700 (PDT) From: Jason Evans Reply-To: Jason Evans To: Peter Wemm Cc: Mike Smith , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc_r Makefile src/lib/libc_r/uthread pthread_private.h uthread_create.c uthread_gc.c uthread_init.c In-Reply-To: <19990705145522.DA40164@overcee.netplex.com.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk On Mon, 5 Jul 1999, Peter Wemm wrote: > Mike Smith wrote: > > > To activate these modifications, add -D_PTHREAD_GSTACK to CFLAGS in > > > src/lib/libc_r/Makefile. Since the modifications depend on the VM_STACK > > > kernel option, I'm not sure how to safely use growable stacks by default. > > > > Build enough evidence that VM_STACK doesn't have any downsides, and > > then make it non-optional. Okay, I've tested this pretty well now, and am convinced that it works on x86. As for alpha, I have no idea, plus VM_STACK isn't enabled by default on alpha (according to the man page), so I only turned on growable stacks for x86. > It's been on by default for 3.1-release and 3.2-release, and has been unable > to be disabled on current for ages. I think it's high time the same happened > on -stable. I have not heard any reports of people needing to disable it. There was some breakage (in at least 3.2 and -current) that Alan Cox fixed a couple of weeks ago. Since then, my tests haven't hit any more problems, but (unless it used to work, and regressed) the VM_STACK code hasn't been stable for very long. VM_STACK might deserve a little more pounding before it's made non-optional. On a somewhat related note, my threads test programs indicate that there is likely a significant memory leak in libc_r. Memory usage grows steadily, even in the steady state of the programs, which indicates to me that the leak is is the scheduler somewhere. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message