From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261763AbUEWKBC (ORCPT ); Sun, 23 May 2004 06:01:02 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262003AbUEWKBC (ORCPT ); Sun, 23 May 2004 06:01:02 -0400 Received: from warden3-p.diginsite.com ([208.147.64.186]:11706 "HELO warden3.diginsite.com") by vger.kernel.org with SMTP id S261763AbUEWKA6 (ORCPT ); Sun, 23 May 2004 06:00:58 -0400 From: David Lang To: Christian Borntraeger Cc: linux-kernel@vger.kernel.org, Gergely Czuczy , itk-sysadm@ppke.hu Date: Sun, 23 May 2004 03:00:51 -0700 (PDT) X-X-Sender: dlang@dlang.diginsite.com Subject: Re: Linux 2.4 VS 2.6 fork VS thread creation time test In-Reply-To: <200405231139.44096.linux-kernel@borntraeger.net> Message-ID: References: <200405231139.44096.linux-kernel@borntraeger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 23 May 2004, Christian Borntraeger wrote: > Date: Sun, 23 May 2004 11:39:41 +0200 > From: Christian Borntraeger > To: linux-kernel@vger.kernel.org > Cc: Gergely Czuczy , itk-sysadm@ppke.hu > Subject: Re: Linux 2.4 VS 2.6 fork VS thread creation time test > > Gergely Czuczy wrote: > > failed. As I told it above all the processes are teminated right after > > creation, but there were a lot of defunct processes in the system, and > > they were only gone when the parent termineted. > > Have you heard of wait, waitpid and pthread_join? there really is some sort of problem with 2.6.6 in this area. I have an app that I am trying to stress test on a dual opteron system and under a heavy load something goes haywire and the children become zombies. on a dual athlon the test manages 2500 forks/sec and can continue forever (Ok, I only tested it to 11M forks at full speed :-), but the dual opteron box manages 3500 connections/sec for a few thousand connections and then stops reaping the children. if I attach strace to the parent at this point the logjam is broken and strace shows the wait calls receiving and handleing the sigchild the prarent deals with sigchild by handler{ while ( wait(...) >0); signal(SIGCHLD, handler); } unfortunantly trying to leave strace attached while running the test slows it down to ~1200 forks/sec and the problem never forms. David Lang -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Brian W. Kernighan