From owner-freebsd-current Sun Jan 26 13:25:40 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id NAA25136 for current-outgoing; Sun, 26 Jan 1997 13:25:40 -0800 (PST) Received: from root.com (implode.root.com [198.145.90.17]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id NAA25127 for ; Sun, 26 Jan 1997 13:25:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id NAA08091; Sun, 26 Jan 1997 13:25:28 -0800 (PST) Message-Id: <199701262125.NAA08091@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Bruce Evans cc: swallace@ece.uci.edu, current@FreeBSD.ORG Subject: Re: exec bug In-reply-to: Your message of "Mon, 27 Jan 1997 00:50:34 +1100." <199701261350.AAA31786@godzilla.zeta.org.au> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 13:25:28 -0800 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >> The only solution I can think of at the moment to this problem would be to >>change the code to do a read of the file header into a malloced buffer. The >>overhead for this would be very (unacceptably) high, however. > >Testing shows that the additional overhead would probably be small and >negative, since it is small and negative outside the kernel. On a P133, >the enclosed program prints the following times for various access sizes: > > mmap read malloc+read >4: 39 22 125 (usec) >32: 40 22 125 >1024: 44 34 135 >4096: 60 72 160 These times are escentially meaningless since the overhead of calling kernel internal routines is very different to doing system calls. The only time that is relevant is the 4K read, anyway. It's very unlikely that you would access more than just a few longwords within the page, but the variety of image formats that we support requires us to bring in a large chunk as the image header. This is ideal for mmap, and bad for read/copy. There is no page fault if the image header is resident due to page table pre-loading, so the cost is very low. Thinking more about this problem, one could use vm_page_lookup() to determine the residency of a page and then call vm_fault directly if the page isn't resident. This would get you the error return if the fault should be fatal. Hmmm. I had originally (when I wrote execve) considered calling vm_fault directly from execve() rather than doing the fault/trap, but the overhead for this was too high for the standard case of the page being resident. I didn't until now consider the possiblity of looking up the page, which might not be prohibitively expensive. Let me think about this some more and perhaps chat with John about it. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project