From owner-freebsd-arch@FreeBSD.ORG Mon Jun 5 17:22:11 2006 Return-Path: X-Original-To: arch@freebsd.org 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 ECAC616A844 for ; Mon, 5 Jun 2006 17:22:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 70EDE43D46 for ; Mon, 5 Jun 2006 17:22:11 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 53EF946C55; Mon, 5 Jun 2006 13:22:10 -0400 (EDT) Date: Mon, 5 Jun 2006 18:22:10 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <20279.1149527318@critter.freebsd.dk> Message-ID: <20060605182136.F68996@fledge.watson.org> References: <20279.1149527318@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Kirk McKusick , Garrett Wollman , arch@freebsd.org Subject: Re: Why use `thread' as an argument of Syscalls? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jun 2006 17:22:19 -0000 On Mon, 5 Jun 2006, Poul-Henning Kamp wrote: > In message <200606051700.k55H0OeJ092393@chez.mckusick.com>, Kirk McKusick write > s: > >> Your above analysis is correct. When we made the pass over the code base to >> eliminate all references to "u." we had also hoped to get rid of all >> references to "curproc". While we were successful with the former, it >> eventually became clear that the latter was not practical. But by that >> time, the convention of passing the current process pointer to Syscall was >> established, and removing it did not seem to be worth the effort. > > It would be a good Junior Kernel Hacker project to try to replace these > passed arguments with curproc and see if a measurable difference in > performance is obtained. Caution should be applied, however: not all threads passed into functions are necessarily curthread, nor all processes curproc. It's the obscure edge places that kill you :-). Robert N M Watson