From owner-freebsd-arch Tue Aug 20 6:32:31 2002 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 4AF4037B400 for ; Tue, 20 Aug 2002 06:32:27 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8512843E4A for ; Tue, 20 Aug 2002 06:32:26 -0700 (PDT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id JAA07142; Tue, 20 Aug 2002 09:32:19 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g7KDVnv27112; Tue, 20 Aug 2002 09:31:49 -0400 (EDT) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15714.17605.575558.398279@grasshopper.cs.duke.edu> Date: Tue, 20 Aug 2002 09:31:49 -0400 (EDT) To: Bruce Evans Cc: Ian Dowse , arch@FreeBSD.ORG Subject: Re: Solving the stack gap issue In-Reply-To: <20020818055951.N12475-100000@gamplex.bde.org> References: <200208171918.aa72556@salmon.maths.tcd.ie> <20020818055951.N12475-100000@gamplex.bde.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bruce Evans writes: > > I'd like normal calls to have a fast path. We're already 1 or 2 layers > slower than Linux. (Linux on i386's does something like > "pushal; call syscalltable(,%eax,4)" for the fast path, so it goes directly > from the lowest layer to sys_foo(), but FreeBSD calls syscall() from the > lowest label and syscall() does lots of relatively slow things.) Is there any chance of getting this fastpath? Or at least making syscall() more streamlined? For example, why do we check MPSAFE and conditionally grab and release GIANT in syscall instead of just grabbing/releasing it in the syscall itself? A few thousand instructions worth of bloat might be worth 2 compares in the critical path.. Also, if the copyin fails, why do we not just set the ret value and jump past the call, rather than setting error and doing an extra compare a few lines later? Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message