From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77006 invoked by alias); 6 Dec 2017 13:13:02 -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 76973 invoked by uid 89); 6 Dec 2017 13:13:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=HContent-Transfer-Encoding:8bit X-HELO: mx1.redhat.com Subject: Re: [RFC] nptl: change default stack guard size of threads To: Wilco Dijkstra , Carlos O'Donell , Szabolcs Nagy , GNU C Library Cc: nd , Jeff Law , Richard Earnshaw , Rich Felker , James Greenhalgh References: <5A1ECB40.9080801@arm.com> <76c38ecf-6497-c96c-5c8c-95cceed100a5@redhat.com> <5A1EFF28.9050406@arm.com> <5c796246-1907-8cf4-00fc-eee11614b092@redhat.com> <56ea7349-b459-355f-6b37-a7fc04ec523d@redhat.com> From: Florian Weimer Message-ID: <4c1f71cd-ebe6-6fa7-a3c4-05b410e31ecd@redhat.com> Date: Wed, 06 Dec 2017 13:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2017-12/txt/msg00165.txt.bz2 On 12/06/2017 02:10 PM, Wilco Dijkstra wrote: > Florian Weimer wrote: >> On 11/29/2017 11:38 PM, Carlos O'Donell wrote: >>> On 11/29/2017 02:28 PM, Wilco Dijkstra wrote: >>>> Why should it be any different from LP64? Typical page size will still be >>>> 64KB, so a 4KB guard would be rounded up to 64KB. An ILP32 system >>>> with 64KB pages could create  ~30000 threads per process. Does that >>>> make it unusable? >>> >>> ... and this is already configurable via pthread_attr_setguardsize(), so >>> you *could* tune a system to have smaller guards against the recommendation >>> of the runtime authors? >> >> Sure, if you recompile your application.  That's not really a solution IMHO. > > You've got to do that already in order to run it on ILP32 - there isn't exactly > a large amount of existing ILP32 binaries around, let alone ones that need more > than 30000 threads per process. I wasn't talking about aarch64 ILP32, and I suspect neither was Carlos. In my world, if you still have 32-bit binaries, it's because you lost the sources or the tools or knowledge to build them at some point. Thanks, Florian