From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-87650-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 3262 invoked by alias); 29 Nov 2017 22:38:59 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 3244 invoked by uid 89); 29 Nov 2017 22:38:58 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=BAYES_00,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=30000
X-HELO: mail-qt0-f175.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:subject:to:cc:references:from:organization
         :message-id:date:user-agent:mime-version:in-reply-to
         :content-language:content-transfer-encoding;
        bh=xuGmrCuJIBmx10ETDwiBTQnRpVTFPtoBY/sB+EplQ7Y=;
        b=ePKX3Gu5IE+QJYMFKbR9+/U0NMB/rKXiIw0Qi6WNMQLnbU3wmVw8NaLEKxU6VhdNlv
         NeTxDHsaTXvcoMRMIlI8KcFk24MUZBcPc9X9e/89+RWHZ5skwnjyZ10dyZ+sVZogwbxi
         zR9kPqc32BHAsn+klBZCy24Cw5RcVUyRj/V2KnOpa4kFAohwVzjWiDyqiR1lzaQd7baG
         PWKF1jhfQP/DD9Uy3bqQyRSZh0THytzCTrgaUCBfz4EENuqq+F7TK8VhytGhYO/+26tu
         JbFpYc2dYal2Q1jvydEnttZs3hIZjLk9AT1I0c+XIniEwNNH9f5qKEr/Tj3wxLLkLTar
         UmIg==
X-Gm-Message-State: AKGB3mJAH7LHdUKqkDRAtLjPelB+S7vTz5thzVBnjbcBPQULe6sz8994
	zpQE6OAR3zR7BnpFlq8sxJ93dQ==
X-Google-Smtp-Source: AGs4zMZB6C+5qck9zPUgHk4v2vUm9YgDANTZTRgFZjwojPYtJinqdznfKGxSZlhvd4fopdBEEgxCqQ==
X-Received: by 10.200.38.133 with SMTP id 5mr706076qto.317.1511995135892;
        Wed, 29 Nov 2017 14:38:55 -0800 (PST)
Subject: Re: [RFC] nptl: change default stack guard size of threads
To: Wilco Dijkstra <Wilco.Dijkstra@arm.com>,
 Florian Weimer <fweimer@redhat.com>, Szabolcs Nagy <Szabolcs.Nagy@arm.com>,
 GNU C Library <libc-alpha@sourceware.org>
Cc: nd <nd@arm.com>, Jeff Law <law@redhat.com>,
 Richard Earnshaw <Richard.Earnshaw@arm.com>, Rich Felker <dalias@libc.org>,
 James Greenhalgh <James.Greenhalgh@arm.com>
References: <5A1ECB40.9080801@arm.com>
 <76c38ecf-6497-c96c-5c8c-95cceed100a5@redhat.com> <5A1EFF28.9050406@arm.com>
 <5c796246-1907-8cf4-00fc-eee11614b092@redhat.com>
 <HE1PR0801MB205834BDB77C2208C953FD2E833B0@HE1PR0801MB2058.eurprd08.prod.outlook.com>
From: Carlos O'Donell <carlos@redhat.com>
Message-ID: <fd118128-6a08-b1a2-a38f-680b46756691@redhat.com>
Date: Wed, 29 Nov 2017 22:38:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <HE1PR0801MB205834BDB77C2208C953FD2E833B0@HE1PR0801MB2058.eurprd08.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2017-11/txt/msg01025.txt.bz2

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?

-- 
Cheers,
Carlos.