Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Jul 2002 13:54:04 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        "Stephane E. Potvin" <sepotvin@videotron.ca>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: NetBSD's uvm_pglistalloc equivalent?
Message-ID:  <3D3487EC.24A7B112@mindspring.com>
References:  <20020715142136.A1012@hades.videotron.ca.> <3D333E03.549F18D0@mindspring.com> <20020716140833.D1012@hades.videotron.ca.>

next in thread | previous in thread | raw e-mail | index | archive | help
"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.

-- Terry

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?3D3487EC.24A7B112>