From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id 6AC39384C007 for ; Fri, 28 Aug 2020 08:38:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 6AC39384C007 Received: by mail-lf1-x12b.google.com with SMTP id q8so290500lfb.6 for ; Fri, 28 Aug 2020 01:38:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=YyEZg+MV011mpR6hr6ZFO/vX+n75n0jbNSzJuTRFzaQ=; b=PtE18qQJwcf3kuNDcl5lVUwn1S6UZGQ1GFq3mb24Zv5MwtLgqddYRjqB/6W+cg09HR lZI5AG7dqdKmfRlLVMgLFPzLOl+WUvcx37zBGlNx/6uaMtiAmkiOm6Wl9O8e+5oro4sn P3ODAltsmxrenXPXj+46foAF99aOavqXjAWOnpwGgxZbvuFO6SxewypMG+SH+CiDvPnw k5M/jIzxbRYt8xfT+mdlQNlkkPc67KI4K7hEHr5bNOh1uhM+ysYTRsNVPy2gXiMj9F4a oVPPyFfYFf5S5UbWIeJhGd99DMFn6Ax6a7gls1JsjWzRWH7Upka/J4FCcPJnNyLuPLBW jBnA== X-Gm-Message-State: AOAM533BWoJmTYDXwEXnjfD0+eEbYnjkt5jT/AL71gZfV0XU6xR5AF4x cGVVsk6zb9D2rG4q4rJml+44od0Hgl4= X-Google-Smtp-Source: ABdhPJy6qrwRdgDqKy6Ln5qRX+uIenlVvoiJugtgVey3r2waWJ7soHHFGZgaUAs4QEjCDj57TqAIpA== X-Received: by 2002:a19:ae0a:: with SMTP id f10mr285657lfc.168.1598603935938; Fri, 28 Aug 2020 01:38:55 -0700 (PDT) Received: from JOKK (87-249-176-245.ljusnet.se. [87.249.176.245]) by smtp.gmail.com with ESMTPSA id e25sm63130ljp.47.2020.08.28.01.38.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Aug 2020 01:38:55 -0700 (PDT) From: To: "'Ken Brown'" , References: <000401d67ba0$8b1f33b0$a15d9b10$@gmail.com> <20200826175724.GQ3272@calimero.vinschen.de> <000701d67c6c$10bcf720$3236e560$@gmail.com> <6d698a32-06bb-a47b-58e6-ceeecca722c9@cornell.edu> In-Reply-To: <6d698a32-06bb-a47b-58e6-ceeecca722c9@cornell.edu> Subject: Sv: Sv: Limit for number of child processes Date: Fri, 28 Aug 2020 10:38:55 +0200 Message-ID: <001101d67d16$aa5db9f0$ff192dd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQI7mQ+hPIKf2raSwP+uxe6Dh/MnugIebBIUAmKifX0CBffj26hOwtwQ X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Aug 2020 08:38:59 -0000 > > Hi Corinna > > > >>> Dear cygwin folks > >>> > >>> It seems like there's a limit of the number of possible child > >>> processes defined to 256 with 'NPROCS' in > >>> //winsup/cygwin/child_info.h used in 'cprocs' in > >>> //winsup/cygwin/sigproc.cc > >>> > >>> 256 is quite few possible children in an enterprise environment and > >>> perhaps the limit should be limited by the physical resources or > >> possibly Windows ? > >> > >> The info has to be kept available in the process itself so we need > >> this array of NPROCS * sizeof (pinfo). > >> > >> Of course, there's no reason to use a static array, the code could > >> just as well use a dynamically allocated array or a linked list. > >> It's just not the way it is right now and would need a patch or > rewrite. > >> > >> As for the static array, sizeof pinfo is 64, so the current size of > >> the array is just 16K. We could easily bump it to 64K with NPROCS > >> raised to > >> 1024 for the next Cygwin release, at least on 64 bit. > >> I don't think we should raise this limit for 32 bit Cygwin, which is > >> kind of EOL anyway, given the massive restrictions. > > > > I don't know the exact purpose of this and how the cprocs is used, but > > I'd prefer something totally dynamic 7 days out of 7 or otherwise > > another limit would just bite you in the ass some other day instead > > ;-) > > > > A linked list could be used if you wanna optimize (dynamic) memory > > usage but an (amortized) array would probably provide faster linear > > search but I guess simplicity of the code and external functionality > > is the most important demands for this choice > > Any change here (aside from just increasing NPROCS) would have to be done > with care to avoid a performance hit. I looked at the history of changes > to sigproc.cc, and I found commit 4ce15a49 in 2001 in which a static array > something like cprocs was replaced by a dynamically allocated buffer in > order to save DLL space. This was reverted 3 days later (commit e2ea684e) > because of performance issues. I wonder what kind of performance issue ? Nevertheless, that old commit didn't make the number of possible children more dynamic though, when it was still restricted to NPROCS (or ZOMBIEMAX/NZOMBIES), it was just not allocated on the stack. But yes, accessing dynamic allocated memory can theoretically be slower than stack allocated memory, but without measuring it one cannot tell ;-) Todays hardware is pretty good at prefetching etc, but as I said, it needs measurements Looking at the code, I didn't see that many searches (though the existing ones could be used excessively) and if that is a bottleneck it could be a good idea to keep the children sorted to be able to do a binary search (that will give random access containers a huge advantage (theoretically)) instead of a linear search I'm confident that you'll find the best solution to this though, but 256 children is not enough, at least, for us BTW, when the limit is reached, errno is set to EAGAIN btw, but would ENOMEM be a more appropriate (regardless if it is NPROCS is reached or that malloc return NULL) ? Best regards, Kristian > Ken