From owner-freebsd-current Tue Dec 2 11:42:32 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA27092 for current-outgoing; Tue, 2 Dec 1997 11:42:32 -0800 (PST) (envelope-from owner-freebsd-current) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA27084 for ; Tue, 2 Dec 1997 11:42:27 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.7) id LAA16742; Tue, 2 Dec 1997 11:42:21 -0800 (PST) (envelope-from sef) Date: Tue, 2 Dec 1997 11:42:21 -0800 (PST) From: Sean Eric Fagan Message-Id: <199712021942.LAA16742@kithrup.com> To: current@freebsd.org Reply-To: current@freebsd.org Subject: Re: cvs commit: src/sys/kern vfs_aio.c In-Reply-To: <2923.881086024.kithrup.freebsd.current@critter.freebsd.dk> References: Your message of "Tue, 02 Dec 1997 09:06:20 PST." <199712021706.JAA28517@kithrup.com> Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <2923.881086024.kithrup.freebsd.current@critter.freebsd.dk> you write: >>is exactly the same speed as: >> >> p->p_retval[0] = 10; > >BZZZTT! Wrong answer. > >We save the time it takes to push the &retval on the stack on ALL syscalls. Versus the time it take sto copy the extra two words around when creating the proc structure, versus the extra size of the proc structure, versus the extra work now being done to deal with it, etc. It takes less than 5 cycles to push the address. That adds up to some degree when dealing with the layers of calls -- that I can see as a savings. But it's insignificant, or should be -- unless you have real numbers to back this up. If it adds up to 0.1% of an average system call time, I would be highly surprised. Sorry, that is *still* not a compelling argument. If you want to make things more efficient, there are some things you can do with FPU emulation that can save a bunch of clock cycles off; or you could think about rewriting how the trap handler itself is done -- that could be improved quite a bit, I think. But it'd probably require more assembly programming.