This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [RFC] nptl: change default stack guard size of threads

From: Florian Weimer <fweimer at redhat dot com>
To: James Greenhalgh <james dot greenhalgh at arm dot com>
Cc: Rich Felker <dalias at libc dot org>, Szabolcs Nagy <Szabolcs dot Nagy at arm dot com>, GNU C Library <libc-alpha at sourceware dot org>, nd <nd at arm dot com>, Jeff Law <law at redhat dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
Date: Tue, 19 Dec 2017 14:06:26 +0100
Subject: Re: [RFC] nptl: change default stack guard size of threads
Authentication-results: sourceware.org; auth=none
References: <5A1ECB40.9080801@arm.com> <76c38ecf-6497-c96c-5c8c-95cceed100a5@redhat.com> <5A1EFF28.9050406@arm.com> <5c796246-1907-8cf4-00fc-eee11614b092@redhat.com> <20171129205148.GG1627@brightrain.aerifal.cx> <00c123b5-dd46-6777-2c24-d80eae8d35df@redhat.com> <20171205105530.GA12966@arm.com> <20171219123446.GA34598@arm.com>

On 12/19/2017 01:34 PM, James Greenhalgh wrote:

Option 1: 64k guard pages for LP64 on AArch64.

Option 2: 4k guard pages for LP64 for AArch64

Our proposal then, having spoken things through with the Arm engineers
here, and taken in to consideration the opinions on this thread, is that
we move to two "blessed" configurations of the GCC support for AArch64.

Are there any Arm engineers who prefer Option 2, or is that just thereto accommodate feedback on libc-alpha?

My main concern was the variance in configurations with Option 1(compared to Option 2). To some extent, the variance with Option 1 istemporary. If both Option 1 and 2 are offered, we have permanentvariance. From my point of view, that's worth that just going withOption 1.

So if this is some sort of consensus proposal, as opposed to actualtechnical requirements which favor Option 2 in some deployments, I thinkthat's not a good idea, and we should go with Option 1 instead.


Thanks,
Florian

Follow-Ups:
- Re: [RFC] nptl: change default stack guard size of threads
  - From: Szabolcs Nagy
- Re: [RFC] nptl: change default stack guard size of threads
  - From: Jeff Law

References:
- Re: [RFC] nptl: change default stack guard size of threads
  - From: James Greenhalgh
- Re: [RFC] nptl: change default stack guard size of threads
  - From: James Greenhalgh

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]