Date: Wed, 17 Jul 2002 10:12:26 -0400 From: "Stephane E. Potvin" <sepotvin@videotron.ca> To: freebsd-hackers@FreeBSD.ORG Subject: Re: NetBSD's uvm_pglistalloc equivalent? Message-ID: <20020717101226.E1012@hades.videotron.ca.> In-Reply-To: <3D3487EC.24A7B112@mindspring.com>; from tlambert2@mindspring.com on Tue, Jul 16, 2002 at 01:54:04PM -0700 References: <20020715142136.A1012@hades.videotron.ca.> <3D333E03.549F18D0@mindspring.com> <20020716140833.D1012@hades.videotron.ca.> <3D3487EC.24A7B112@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020717101226.E1012>