From owner-freebsd-arch@FreeBSD.ORG Sat May 10 12:26:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35ADF37B401; Sat, 10 May 2003 12:26:37 -0700 (PDT) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93EBF43F85; Sat, 10 May 2003 12:26:36 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0084.cvx40-bradley.dialup.earthlink.net ([216.244.42.84] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19EZzO-0006mO-00; Sat, 10 May 2003 12:26:36 -0700 Message-ID: <3EBD5212.225AC129@mindspring.com> Date: Sat, 10 May 2003 12:25:06 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Schultz References: <20030510172609.GA29039@HAL9000.homeunix.com> <3EBD4214.73CB8B7C@mindspring.com> <20030510191352.GA225@HAL9000.homeunix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a458bed8b69e3e694ea767706062570ee42601a10902912494350badd9bab72f9c350badd9bab72f9c cc: arch@FreeBSD.ORG cc: John Baldwin Subject: Re: [Bikeshed] sigacts locking X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2003 19:26:37 -0000 David Schultz wrote: > No, they're already wired kernel pages that are unwired and > unmapped when the process is swapped out. Moreover, there's > probably *more* KVA pressure with upages swapping, because each > tiny struct upages gets a 4K or larger page all to itself unless > it's swapped out. The wiring and unwiring doesn't change the fundamental nature of the page. I can think of a lot of useful things to put in that page, if you are willing to map it read-only into user space. The pid, uid, gid, ppid, etc. could all be made zero system call functions, for example. So I'm not as concerned about it being 4K in size. I'm more concerned with the idea of being able to migrate a process to another node in a cluster, and having all of the information needed to do this outside nominally kernel data structures, instead of having to do a lot of work to extricate the process from a given node's kernel data. (Well, you *did* wan us in the "Subject:"... 8-) 8-)). -- Terry