From owner-freebsd-hackers Mon Sep 23 01:14:08 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id BAA17929 for hackers-outgoing; Mon, 23 Sep 1996 01:14:08 -0700 (PDT) Received: from zwei.siemens.at (zwei.siemens.at [193.81.246.12]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id BAA17873 for ; Mon, 23 Sep 1996 01:14:00 -0700 (PDT) Received: from sol1.gud.siemens.co.at (root@[10.1.143.100]) by zwei.siemens.at (8.7.5/8.7.3) with SMTP id KAA18862 for ; Mon, 23 Sep 1996 10:12:48 +0200 (MET DST) Received: from ws2301.gud.siemens.co.at by sol1.gud.siemens.co.at with smtp (Smail3.1.28.1 #7 for ) id m0v568m-00020CC; Mon, 23 Sep 96 10:13 MET DST Received: by ws2301.gud.siemens.co.at (1.37.109.16/1.37) id AA175676096; Mon, 23 Sep 1996 10:08:16 +0200 From: "Hr.Ladavac" Message-Id: <199609230808.AA175676096@ws2301.gud.siemens.co.at> Subject: Re: thread stacks and protections (was Re: attribute/inode caching) To: terry@lambert.org (Terry Lambert) Date: Mon, 23 Sep 1996 10:08:16 +0200 (MESZ) Cc: michaelh@cet.co.jp, terry@lambert.org, freebsd-hackers@FreeBSD.org In-Reply-To: <199609201801.LAA02736@phaeton.artisoft.com> from "Terry Lambert" at Sep 20, 96 11:01:58 am X-Mailer: ELM [version 2.4 PL24 ME8a] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk 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