From owner-freebsd-current Sun Jan 26 14:07:59 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27426 for current-outgoing; Sun, 26 Jan 1997 14:07:59 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id OAA27419 for ; Sun, 26 Jan 1997 14:07:55 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.8.3/8.6.9) id JAA10308; Mon, 27 Jan 1997 09:02:02 +1100 Date: Mon, 27 Jan 1997 09:02:02 +1100 From: Bruce Evans Message-Id: <199701262202.JAA10308@godzilla.zeta.org.au> To: bde@zeta.org.au, dg@root.com Subject: Re: exec bug Cc: current@FreeBSD.ORG, swallace@ece.uci.edu 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. They give a small upper bound for the case that everything is in a cache. See other mail for more relevant times on a 486/33. On a P133, I get the following times for 1 iteration: kernel vm_mmap for /bin/cp in execve(): 28 usec kernel vm_map_remove for /bin/cp in execve(): 12 usec user read and lseek of 32 bytes from /bin/cp: 45-60 usec >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. The image activators should read the part that they need. They might need to do this anyway if their headers are larger than 1 page. > 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 Or just allocate a buffer for it and access the buffer directly. This works especially well if the buffer is already mapped into buffer_map because it avoids the overhead for setting up and tearing down the mapping into exech_map. There may be locking problems with both methods. Bruce