Date: Mon, 27 Jan 1997 09:47:26 +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: <199701262247.JAA11690@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>>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. No, my user space times show that a user read() takes about the same time as kernel mapping (50 usec = less than 5% of the time for a static-library fork-exec-exit, and less than 0.6% of the time for a shared-library fork-exec-exit. read() should be slightly faster in the kernel. >>Or just allocate a buffer for it and access the buffer directly. This > 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. My user space times show that it wouldn't have much more initial overhead. Lookup of mapped in-core buffers is very efficient - hashing works well. If there is a slowdown later due to the file being accessed using a different method, then the unified vm must not be very unified. I don't think it is that bad :-). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701262247.JAA11690>