At 9:24 AM -0700 10/8/01, Peter Wemm wrote: >Using the same next address means that you dont have to put padding in the >file itself, and can simply double map the same page when loading >executables.
Thanks for the explanation...it now makes sense why this was done (at least for userland executables). >Anyway, that is why it was done that way. What is or isn't good for >application executables doesn't necessarily apply to the kernel since it >isn't demand paged. > >In the kernel case the larger file size may actually end up using one less >page of actual memory for the kernel data segment. However, I seem to >recall Bruce telling me once that the 4MB page implementation breaks >something with the text read-only protection, so doing any roundup at all >is probably futile. Hmmm, I didn't get a strong sense of "do it" or "don't do it" for applying my patch. It sounds like applying it in the kernel ldscript (which is what I was looking at) wouldn't hurt. >Incidently, I have long been tempted to make a similar change to the >*userland* elf executable layout. I think this will significantly speed up >executable exec() times since we wont have to do the silly BSS pre-zero on >the bounary page, which will case an out-of-order page read. If the VM >system supported a "post faultin" callback hook we could avoid that. This sounds like something to put onto a project list for people to work on. Mark To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
