From owner-freebsd-hackers Mon Dec 9 6:54:55 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 090AF37B401; Mon, 9 Dec 2002 06:54:53 -0800 (PST) Received: from apache.metrocom.ru (www.metrocom.ru [195.5.128.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53D7943F37; Mon, 9 Dec 2002 06:54:51 -0800 (PST) (envelope-from alex@metrocom.ru) Received: from apache.metrocom.ru (localhost [127.0.0.1]) by apache.metrocom.ru (8.12.6/8.12.6) with ESMTP id gB9EsktQ018825; Mon, 9 Dec 2002 17:54:46 +0300 (MSK) Received: from localhost (alex@localhost) by apache.metrocom.ru (8.12.6/8.12.6/Submit) with ESMTP id gB9EskDw018822; Mon, 9 Dec 2002 17:54:46 +0300 (MSK) X-Authentication-Warning: apache.metrocom.ru: alex owned process doing -bs Date: Mon, 9 Dec 2002 17:54:46 +0300 (MSK) From: Varshavchick Alexander To: David Schultz Cc: Terry Lambert , , Subject: Re: maxusers and random system freezes In-Reply-To: <20021206134724.GA16965@HAL9000.homeunix.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi David, Thanks, you're a genuis, didn't you know that? Your patch worked perfectly :) However, it didn't solve the random freezes problem. The server felt relieved a bit, load average value pushed down a little, so when the server is working, this change did him good. Now more about a state when the server sleeps. It behaves as though the load average has suddently fired to some immense value - the system responds to ping, but all other activity has almost halted. It's not like the server went to a swap, because it occurs practically instantly, and this state goes for hours. The system is lacking some resources, or may be a bug somewhere, can you give any hints to it? My best wishes ---- Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Fri, 6 Dec 2002, David Schultz wrote: > Date: Fri, 6 Dec 2002 05:47:24 -0800 > From: David Schultz > To: Varshavchick Alexander > Cc: Terry Lambert , freebsd-questions@FreeBSD.ORG, > freebsd-hackers@FreeBSD.ORG > Subject: Re: maxusers and random system freezes > > Thus spake Varshavchick Alexander : > > On Fri, 6 Dec 2002, David Schultz wrote: > > > > > Thus spake Varshavchick Alexander : > > > > Well, now I made KVA space 2G, we'll see later on if it helps to get rid > > > > of the sudden system halts, but for some reason a side-effect has > > > > appeared: pthread_create function returns EAGAIN error now, so I had to > > > > recompile the software using it with linux threads to make it working. > > > > With the old kernel these pieces worked without problems. Can it be that > > > > somehow the enlarged KVA space messed up with the threads mechanism? > > > > > > I'm not a pthreads expert, but my best guess is that your program > > > tried to create a thread with a stack address that was too high. > > > Remember that with a 2 GB KVA, user processes have only 2 GB to > > > play with instead of 3 GB, so attempting to mmap() a stack above > > > about 2 GB would cause pthread_create() to return EAGAIN. > > > > > > > Yes this makes sense, however this call to pthread_create didn't specify > > any special addresses for the new thread. The pthread_create was called > > with the NULL attribute which means that the system defaults were being > > used. Something in the system has gone wrong... > > I just glanced at the source in -STABLE, and it appears to be a > pthreads bug. (Then again, maybe I'm missing something, since > nobody seems to have noticed this before.) The default address at > which new thread stacks are created is just below the main stack. > This address is based on the lexical constant USRSTACK, but it > should be initialized in uthread_init() based on the kern.usrstack > value returned by sysctl. (The correct value is already used to > map the main stack's red zone.) The result is that you need to > make world and recompile any apps statically linked against > pthreads after building your new kernel in order to get things to > work. > > I don't have time to fiddle with pthreads until after Christmas, > but you might see if the following patch (against -STABLE) helps > when you reduce the configured KVA size without remaking pthreads. > > Index: uthread/uthread_init.c > =================================================================== > RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_init.c,v > retrieving revision 1.23.2.10 > diff -u -r1.23.2.10 uthread_init.c > --- uthread/uthread_init.c 2002/10/22 14:44:03 1.23.2.10 > +++ uthread/uthread_init.c 2002/12/06 13:41:06 > @@ -245,6 +245,8 @@ > len = sizeof (int); > if (sysctl(mib, 2, &_usrstack, &len, NULL, 0) == -1) > _usrstack = (void *)USRSTACK; > + _next_stack = _usrstack - PTHREAD_STACK_INITIAL - > + PTHREAD_STACK_DEFAULT - (2 * PTHREAD_STACK_GUARD); > /* > * Create a red zone below the main stack. All other stacks are > * constrained to a maximum size by the paramters passed to > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message