From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124723 invoked by alias); 29 Nov 2017 18:29:22 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 124711 invoked by uid 89); 29 Nov 2017 18:29:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=0.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KB_WAM_FROM_NAME_SINGLEWORD,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 spammy=cuts, do.=c2, reward, held?= X-HELO: brightrain.aerifal.cx Date: Wed, 29 Nov 2017 18:29:00 -0000 From: Rich Felker To: Carlos O'Donell Cc: Florian Weimer , Szabolcs Nagy , GNU C Library , nd@arm.com, Jeff Law , Richard Earnshaw , Wilco Dijkstra , James Greenhalgh Subject: Re: [RFC] nptl: change default stack guard size of threads Message-ID: <20171129182909.GE1627@brightrain.aerifal.cx> References: <5A1ECB40.9080801@arm.com> <76c38ecf-6497-c96c-5c8c-95cceed100a5@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2017-11/txt/msg01010.txt.bz2 On Wed, Nov 29, 2017 at 10:16:54AM -0800, Carlos O'Donell wrote: > On 11/29/2017 07:18 AM, Florian Weimer wrote: > > On 11/29/2017 03:59 PM, Szabolcs Nagy wrote: > >> The change can be made for aarch64 only > > > > That doesn't seem to be the case, looking at the patch. > > > > So what you intended to do, exactly? > > > > A 64 KiB probe interval on legacy 32-bit architectures is really a > > no-go. It means we have to increase the guard region size to 64 KiB. > > But we cannot do that: The guard allocation comes out of the overall > > thread stack size, and existing applications do not expect that 60K > > of configured stack suddenly becomes unavailable. Adding the guard > > size on top of the allocation will break setups which are carefully > > tuned for a maximum number of threads. > > We cannot be held to account for carefully tuned applications, such > applications have to be tuned again for newer glibc. > > I think we *could* do this for 64-bit and 32-bit AArch64/ARM, but I > don't see the value in doing it for 32-bit. If 64k guard is mandatory for safety against jumping over the guard zone, then I don't think it's possible to "re-tune" 32-bit apps for the new requirement. This imposes a relatively small limit on possible number of threads the process can create. > > And that's what people actually do.  Here's an example: > > > > “ > >  -Xss128k > > > > Reduces the default maximum thread stack size, which allows more of the process' virtual memory address space to be used by the Java heap. > > ” > > > > > > > > We can likely support 64 KiB probe intervals on 64-bit architectures. > > But given the impact on backwards compatibility, I really don't see > > the benefit on (legacy) 32-bit. > > I agree, this is expensive for 32-bit, without much reward. > > Even on 64-bit, I would like to see bug 11787 fixed to move the guard > page accounting out of the stack, and then you can make the guard page > as big as you want without impacting the stack accounting. I agree completely that guard page should not subtract from the usable stack size but should be in addition to it. If glibc is not currently behaving that way, I think it's a conformance bug. But making it big on 32-bit quickly cuts into total available virtual address space if you have a moderately large number of threads. Rich