From owner-freebsd-hackers Tue Oct 9 9: 1:35 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from alpo.whistle.com (s206m1.whistle.com [207.76.206.1]) by hub.freebsd.org (Postfix) with ESMTP id EFADD37B405 for ; Tue, 9 Oct 2001 09:01:30 -0700 (PDT) Received: from [207.76.207.129] (PBG4.whistle.com [207.76.207.129] (may be forged)) by alpo.whistle.com (8.9.1a/8.9.1) with ESMTP id JAA21211 for ; Tue, 9 Oct 2001 09:01:30 -0700 (PDT) Mime-Version: 1.0 X-Sender: mark-ml@207.76.206.1 Message-Id: In-Reply-To: <20011008162444.BAD02380F@overcee.netplex.com.au> References: <20011008162444.BAD02380F@overcee.netplex.com.au> Date: Tue, 9 Oct 2001 09:01:05 -0700 To: freebsd-hackers@FreeBSD.ORG From: Mark Peek Subject: Re: Change to ldscript.i386 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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