Date: Mon, 23 Sep 1996 10:08:16 +0200 (MESZ) From: "Hr.Ladavac" <lada@ws2301.gud.siemens.co.at> To: terry@lambert.org (Terry Lambert) Cc: michaelh@cet.co.jp, terry@lambert.org, freebsd-hackers@FreeBSD.org Subject: Re: thread stacks and protections (was Re: attribute/inode caching) Message-ID: <199609230808.AA175676096@ws2301.gud.siemens.co.at> In-Reply-To: <199609201801.LAA02736@phaeton.artisoft.com> from "Terry Lambert" at Sep 20, 96 11:01:58 am
next in thread | previous in thread | raw e-mail | index | archive | help
E-mail message from Terry Lambert contained: > [ some discussion deleted ] > So mapped text objects (the program and shared library code) and mapped > heap objects (the program data and shared library data) remain the same > from thread to thread, but the page mapping and guard page mapping for > each thread is the only stack mapping for the given process. > > This implies a heavier-than-expected mapping overhead. > > Another alternative is a hybrid approach: You zone for some amount, > and then after you exceed your zone for a given thread, you engage > in pmap changes. This "punishes" threads with "excessive" stack > use, while leaving other threads unadulterated. It's probably the > correct approach, if the stack can be made arbitrarily large. I have a problem with thread stacks in separate VM spaces. This, namely, means that an RPC call that doesn't leave the process space cannot be fully optimized away because I can not use auto variables as my result areas without an additional copy. Same applies to the [in] arguments, as well. What I want to say is that one thread cannot pass another thread an address to an object on its stack. This is probably worth considering during design. /Marino
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199609230808.AA175676096>