Date: Sun, 26 Jan 1997 13:25:28 -0800 From: David Greenman <dg@root.com> To: Bruce Evans <bde@zeta.org.au> Cc: swallace@ece.uci.edu, current@FreeBSD.ORG Subject: Re: exec bug Message-ID: <199701262125.NAA08091@root.com> In-Reply-To: Your message of "Mon, 27 Jan 1997 00:50:34 %2B1100." <199701261350.AAA31786@godzilla.zeta.org.au>
next in thread | previous 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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701262125.NAA08091>