From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11943 invoked by alias); 1 Apr 2012 19:47:38 -0000 Received: (qmail 11934 invoked by uid 22791); 1 Apr 2012 19:47:37 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 01 Apr 2012 19:47:26 +0000 From: "carlos_odonell at mentor dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug libc/11787] Program with large TLS segment fails aio_write Date: Sun, 01 Apr 2012 19:47:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: carlos_odonell at mentor dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: carlos_odonell at mentor dot com X-Bugzilla-Target-Milestone: 2.16 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-04/txt/msg00002.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=11787 --- Comment #26 from Carlos O'Donell 2012-04-01 19:46:32 UTC --- (In reply to comment #25) > There's no perfect solution here. I wonder if we could come up with a good > heuristic based on the relative sizes of the TLS and thread requested stack. > If the TLS is sufficiently small relative to the size of the requested stack, > then just fold the TLS into the requested stack like we've always done. > Otherwise, add the size of the TLS to the size of the requested stack (rounding > to a page of course). Harder to document and implement, but seems like it'd > strike a better balance. > > I don't know where the cutoff should be, 1%, 10%, 50%? Some experimentation may > guide us. Jeff, Thank you for your feedback. I'll consider this as feedback from Red Hat :-) I'll will work on a fix for this issue. I'm going to consider slightly more than just TLS size in the heuristic though. In truth all of the following contribute to the implementation-defined space that is "stolen" from the stack: (a) alignment requirements (b) static tls (c) guard page (d) pthread descriptor (e) minimal rest stack (f) coloring increment (g) TLS TCB/DTV size On top of this I have "stack grows up" patches from HPPA that need applying to pthread_create.c and allocatestack.c which I'll work into the fixup. I'll post incremental patches to libc-alpha showing each step of the cleanup. I also noticed there are some weird pieces of code like: /* Adjust the stack size for alignment. */ size &= ~__static_tls_align_m1; assert (size != 0); Which makes *no* sense to me. It should make size larger and avoid the assert (this is the case where we allocate our own stack). Which brings me to yet another issue I'm going to fix *before* I start work on this issue: We need generic macros for aligning up and aligning down correctly. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.