Date: Tue, 9 Oct 2001 09:01:05 -0700 From: Mark Peek <mark@whistle.com> To: freebsd-hackers@FreeBSD.ORG Subject: Re: Change to ldscript.i386 Message-ID: <p05101004b7e8cce4fba6@[207.76.207.129]> In-Reply-To: <20011008162444.BAD02380F@overcee.netplex.com.au> References: <20011008162444.BAD02380F@overcee.netplex.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101004b7e8cce4fba6>