This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/11787] Program with large TLS segment fails aio_write
- From: "ppluzhnikov at google dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sources dot redhat dot com
- Date: Sat, 24 Mar 2012 17:39:41 +0000
- Subject: [Bug libc/11787] Program with large TLS segment fails aio_write
- Auto-submitted: auto-generated
- References: <bug-11787-131@http.sourceware.org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=11787
--- Comment #15 from Paul Pluzhnikov <ppluzhnikov at google dot com> 2012-03-24 17:39:41 UTC ---
(In reply to comment #14)
> the increased size should only matter if the new size pushes past a page
> boundary right ? and even then, it'd only be 4KiB per thread ?
We really have to be careful when talking about "size".
The actual used memory (RSS) is unchanged, only the reserved
size (VM) is changing.
To re-state Carlos' example, consider a 32-bit application that creates
1000s of threads, and has large TLS (1000s of __thread variables).
Each thread is created with 64K stack (just barely sufficient to
accomodate all of TLS variables) and otherwise does not use much
of stack (e.g. a non-recursive computation).
This application works fine currently.
Under proposed change, the actual stack usage (RSS) is unchanged,
but the reserved (VM) stack size for each thread nearly doubles
to 64K+__static_tls_size.
So the application would only be able to create half as many
threads as it used to.
I assert that this is a contrived example, and has a trivial fix:
reduce 64K to 4K (or whatever *actual* stack the threads use).
But I will go ahead and contact distribution maintainers,
as Carlos suggested in comment#10.
--
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.