From owner-freebsd-current Sun Jan 26 14:15:42 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id OAA27797 for current-outgoing; Sun, 26 Jan 1997 14:15:42 -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 OAA27776 for ; Sun, 26 Jan 1997 14:15:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by root.com (8.7.6/8.6.5) with SMTP id OAA08418; Sun, 26 Jan 1997 14:15:16 -0800 (PST) Message-Id: <199701262215.OAA08418@root.com> X-Authentication-Warning: implode.root.com: Host localhost [127.0.0.1] didn't use HELO protocol To: Bruce Evans cc: current@FreeBSD.ORG, swallace@ece.uci.edu Subject: Re: exec bug In-reply-to: Your message of "Mon, 27 Jan 1997 09:02:02 +1100." <199701262202.JAA10308@godzilla.zeta.org.au> From: David Greenman Reply-To: dg@root.com Date: Sun, 26 Jan 1997 14:15:16 -0800 Sender: owner-current@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk >>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