On Fri, May 13, 2005 at 06:45:35PM +0100, Matthew Wilcox wrote: > On Fri, May 13, 2005 at 01:21:48PM -0400, Daniel Jacobowitz wrote: > > On Fri, May 13, 2005 at 05:38:33PM +0100, Matthew Wilcox wrote: > > > On Fri, May 13, 2005 at 12:17:18PM -0400, Daniel Jacobowitz wrote: > > > > 27319 mmap(NULL, 1073741824, PROT_READ|PROT_WRITE|PROT_EXEC, > > > > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0 <unfinished ...> > > > > 27319 <... mmap resumed> ) = -1 ENOMEM (Cannot allocate > > > > memory) > > > > > > > > Right now I don't think we could even rebuild glibc -21. The hppa > > > > machines are configured with ulimit -s set to 1GB. This makes > > > > LinuxThreads use 1GB thread stacks. Which is, um, pretty bad. > > > > > > PA machines grow the stack upwards, starting at 0xffffffff - hard > > > stack limit. glibc never used to pay attention to the stack limit, > > > choosing always to use 4MB stacks (iirc). When did glibc change that? > > > > Probably when Carlos added a patch to glibc which defined > > FLOATING_STACKS. Glibc throttles the size to 8MB if the rlimit is > > infinity, but trusts the rlimit if it is explicitly larger than 8MB. > > Ugh. Can we change the logic there to throttle to 8MB if the rlimit is > larger than 1GB and we're building a 32-bit libc?
In the future? Probably, ask Carlos. But for sarge, I'd much rather not make additional changes. -- Daniel Jacobowitz CodeSourcery, LLC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
