From owner-freebsd-hackers Wed Jul 17 6:16: 5 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 590E237B400 for ; Wed, 17 Jul 2002 06:16:01 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 673EA43E3B for ; Wed, 17 Jul 2002 06:16:00 -0700 (PDT) (envelope-from sepotvin@videotron.ca) Received: from hades.videotron.ca ([24.203.254.196]) by relais.videotron.ca (Videotron-Netscape Messaging Server v4.15 MTA-PRD3) with ESMTP id GZEA6M00.6DK for ; Wed, 17 Jul 2002 09:15:58 -0400 Received: from hades.videotron.ca. (localhost [127.0.0.1]) by hades.videotron.ca. (8.12.3/8.12.3) with ESMTP id g6HECRPh059112 for ; Wed, 17 Jul 2002 10:12:27 -0400 (EDT) (envelope-from spotvin@hades.videotron.ca) Received: (from spotvin@localhost) by hades.videotron.ca. (8.12.3/8.12.3/Submit) id g6HECQdQ059111 for freebsd-hackers@FreeBSD.ORG; Wed, 17 Jul 2002 10:12:26 -0400 (EDT) Date: Wed, 17 Jul 2002 10:12:26 -0400 From: "Stephane E. Potvin" To: freebsd-hackers@FreeBSD.ORG Subject: Re: NetBSD's uvm_pglistalloc equivalent? Message-ID: <20020717101226.E1012@hades.videotron.ca.> Mail-Followup-To: freebsd-hackers@FreeBSD.ORG References: <20020715142136.A1012@hades.videotron.ca.> <3D333E03.549F18D0@mindspring.com> <20020716140833.D1012@hades.videotron.ca.> <3D3487EC.24A7B112@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3D3487EC.24A7B112@mindspring.com>; from tlambert2@mindspring.com on Tue, Jul 16, 2002 at 01:54:04PM -0700 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 On Tue, Jul 16, 2002 at 01:54:04PM -0700, Terry Lambert wrote: > "Stephane E. Potvin" wrote: > > > How often must this be allocated? > > > > > > How many of them are needed? > > > > > > If you only need a small set number of them, then they can be > > > allocated very early on in the system lifetime, which means > > > you should allocate them in machdep.c, with the rest of the > > > memory overlay which attempts to make memory in protected mode > > > look like physical RAM. > > > > I need one per process to hold the L1PT of the process' vm space. I will > > probably implement a cache to avoid creating/destroying repetitively but I > > don't think that it's reasonable to preallocate them as it will wire too > > much physical memory. > > So your answers are: > > o Allocated on every fork, freed on every exit > > o One per process > > I don't know how you have the ARM memory map laid out. One thing > that FreeBSD does -- and why I suggested machdep.c -- is to map > out page mappings, without providing backing store for those > mappings until later. > > I guess I need a clarification on your original statement: > > > > > table of the StrongARM processor is four pages. These pages > > > > need to be allocated contiguously. > > The questions are: > > o Contiguous in physical memory? yes/no > > o Contiguous in kernel virtual memory? yes/no > > o Mapped at all in user virtual memory? yes/no > > o Contiguous in user virtual memory? yes/no > > If it's just in kernel virtual memory, then the approach I > suggested -- using machdep.c -- is the correct one. > Ok, here are your answers: 1. Contiguous in physical memory? yes 2. Contiguous in kernel virtual memory? not mandatory but would be nice 3. Mapped at all in user virtual memory? no 4. Contiguous in user virtual memory? no This memory area is for the l1 table and is similar to the x86 l1 table, the only difference is the size of the table. On x86 processors, you have 1024 l1 entries (for a total of 4096 bytes or one physical page) per l1 table and each l2 table is 1024 entries (for a total of 4096 bytes or one physical page). In the ARM case, there is 4096 l1 entries (for a total of 16384 bytes or four physical pages) per l1 table and each l2 table is 256 entries (for a total of 1024 bytes or four l2 tables per physical page). The l1 table is mainly accessed by the processor as part of the virtual->physical translation and must be contiguous in physical memory for that reason. Steph To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message