Date: Sun, 26 Jan 1997 14:15:16 -0800 From: David Greenman <dg@root.com> To: Bruce Evans <bde@zeta.org.au> Cc: current@FreeBSD.ORG, swallace@ece.uci.edu Subject: Re: exec bug Message-ID: <199701262215.OAA08418@root.com> In-Reply-To: Your message of "Mon, 27 Jan 1997 09:02:02 %2B1100." <199701262202.JAA10308@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
>>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. Uh, no. Not unless you want our exec time to be about 5 times higher than linux. The process of mapping the image header is a major portion of the overhead of exec. > They might >need to do this anyway if their headers are larger than 1 page. Yes, but it turns out that this is almost never true. >> 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. Hmmm. From an architectural perspective, this sounds really kludgy. I especially don't like the fact that buffers aren't of a constant size. In the end, I think doing the buffer thing would have much more overhead than what I'm doing now. -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?199701262215.OAA08418>