Date: Thu, 12 Nov 98 14:26:22 -0600 From: "Richard Seaman, Jr." <lists@tar.com> To: "green@unixhelp.org" <green@unixhelp.org>, "Luoqi Chen" <luoqi@watermarkgroup.com> Cc: "current@FreeBSD.ORG" <current@FreeBSD.ORG> Subject: Re: RFSIGSHARE ready? Message-ID: <199811122026.OAA17559@ns.tar.com>
next in thread | raw e-mail | index | archive | help
On Thu, 12 Nov 1998 14:17:43 -0500 (EST), Luoqi Chen wrote: >> 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. Well, you no doubt are right. I only said what I did because I've tried running linux threads in FreeBSD "native". Granted, the signal handling wasn't quite right, and maybe that was and still is the problem I experienced. But, my experience was that my test app would hang during the creation of the first thread *unless* I *both* increased the stack size to a non-zero value *and* moved it out of the process stack area. That's why I said it didn't seem to be a good idea to put zero size (or larger) thread stacks into the process stack area. I'll try it all again when the signal handling is fixed. 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?199811122026.OAA17559>