Date: Mon, 27 Jan 1997 09:02:02 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, dg@root.com Cc: current@FreeBSD.ORG, swallace@ece.uci.edu Subject: Re: exec bug Message-ID: <199701262202.JAA10308@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701262202.JAA10308>