From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16758 invoked by alias); 9 Apr 2008 12:25:54 -0000 Received: (qmail 16738 invoked by uid 22791); 9 Apr 2008 12:25:52 -0000 X-Spam-Check-By: sourceware.org Received: from 204-133-123-27.dia.static.slbbi.com (HELO mail.chez-thomas.org) (204.133.123.27) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 09 Apr 2008 12:25:35 +0000 Received: by mail.chez-thomas.org (Postfix, from userid 999) id 4D0843379090; Wed, 9 Apr 2008 06:25:33 -0600 (MDT) Received: from hermes.chez-thomas.org (hermes_local [192.168.1.101]) by mail.chez-thomas.org (Postfix) with ESMTP id ED0D03379090; Wed, 9 Apr 2008 06:25:29 -0600 (MDT) Message-ID: <47FCB5B8.3030909@mlbassoc.com> Date: Wed, 09 Apr 2008 16:10:00 -0000 From: Gary Thomas User-Agent: Thunderbird 2.0.0.12 (X11/20080226) MIME-Version: 1.0 To: Grant Edwards CC: ecos-discuss@sources.redhat.com References: <20080408202951.GH3552@lunn.ch> <47FCADB8.1000509@mlbassoc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Re: "PANIC: zinit: Out of memory" when num sockets increased to 64 X-SW-Source: 2008-04/txt/msg00152.txt.bz2 Grant Edwards wrote: > On 2008-04-09, Gary Thomas wrote: > >>> Several other people seem to have tripped over this bug. IMO, >>> the problem is that the default value takes the number of >>> sockets into account, and the description claims that value is >>> guaranteed to allow the network stack to start up. >>> >>> One presumes that the minimum value required for stack startup >>> could be calculated at configure time based on the max number >>> of sockets. Since that isn't being done, should I submit a >>> patch that would change the description so that it doesn't say >>> that it is? >> Or, better yet, improve the CDL so it behaves as folks expect :-) > > That would definitely be better. I presume if the formula for > the required amount of memory were known somebody would have > fixed the CDL already. > > Is it practical to figure out how much is required by > statically examining the source code, or would it be simpler to > just do it emperically/experimentally? > The formula that's in place was done by me, examining the code. I think the problem is that since I made that analysis, additional terms have been introduced (e.g. back then, there was no/little notion of file descriptors). These terms should be figured into the result. Of course, it gets a bit tricky as one wants the number to "work" regardless of the configuration (e.g. you _might_ build a system where there is no file system, so the number of file descriptors is unknown, but you still want the computation to be correct). It's this sort of "moving target" (new features, variable configurations, ...) that have made some configuration metrics a bit hard to manage. For example, why must one increase the number of open files in [at least] two places, when surely one should suffice? Anything you can do so suggest improvements will surely be useful and considered for adoption. -- ------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------ -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss