Date: Thu, 12 Nov 1998 14:17:43 -0500 (EST) From: Luoqi Chen <luoqi@watermarkgroup.com> To: green@unixhelp.org, lists@tar.com Cc: current@FreeBSD.ORG Subject: Re: RFSIGSHARE ready? Message-ID: <199811121917.OAA24040@lor.watermarkgroup.com>
next in thread | raw e-mail | index | archive | help
> 2) linux threads creates stacks for each thread it creates via > mmap. It decides on where to start allocating them using the > following algorithm (I think). > > It gets the stack pointer of the initial thread, > figures the initial thread can get by with 2*STACK_SIZE > bytes (4MB in this case), and then starts allocating > thread user stacks 2*STACK_SIZE below the initial > thread stack. > > I don't pretend to really understand FreeBSD vm, to the following > is just a guess on my part. Maybe someone else can shed more > light on this. > > The problem is that FreeBSD dedicates 64MB for a process stack > (ie. for the initial thread), so that linux threads starts out > mmaping into the initial thread stack region. I don't know > exactly what happens at that point, but it doesn't seem to > be good. > I don't see anything bad, if the initial thread doesn't use more than 2*STACK_SIZE. > I'm not sure why FreeBSD mmap allows a mmap into the process > user stack to succeed (but it appears to). > Why not? The only difference user stack from other user memory is the kernel imposes an autogrow policy. > You could consider patching either linux_mmap or the FreeBSD > mmap to reject attempts to mmap at virtual addresses above > p->p->vmspace->vm_maxaddr. I haven't tried this, so I don't > know if it will work. > > What this would do to an unmodified linux threads implementation > would be (I think) that the first 31 or 32 stack addresses it > tries to create would fail since they are trying to map into > the initial thread stack. But, after that, mmaps should succeed > and maybe the addresses will be ok. You'd loose the ability to > create 31 or 32 threads out of the total 1024 that linux threads > allows, but that wouldn't be the end of the world. > The first 31 threads are fine, in fact, they will enjoy the benefit of the autogrow policy on the user stack. > 3) You need to deal with the fact that linux threads mmaps the > thread stacks with the MAP_GROWSDOWN option. Your choices would > appear to be to re-write the FreeBSD mmap syscall to implement > this feature, or to hack linux_mmap. A hack to linux_mmap that > might work (but its a bad hack) would be that when linux_mmap > detects the MAP_GROWSDOWN option it would expand the size > of the mmap request by STACK_SIZE - INITIAL_STACKSIZE, and > relocate the address requested down by the same amount. > This is good enough, it's just a little more VM overcommit. A MAP_GROWSDOWN option without specifying how far it can grow is IMHO a bad idea. > I haven't tried any of these ideas, so I have no clue if they > will work. > -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811121917.OAA24040>