On Wed, Jul 20, 2005 at 04:10:42PM -0700, Matt Thomas wrote:
> Simon Burge wrote:
> >Matt Thomas wrote:
> >>
> >>I would use pools, not malloc/free.
> >
> >
> >Have you considered using UVM anonymous memory objects (aobjs) instead
> >of pools and malloc/free?  Pools and malloc both use wired memory only,
> >whereas an aobj can be pageable.
> >
> >There was some discussion about this ages ago on tech-kern.  Some
> >starting points are:
> >
> > http://mail-index.netbsd.org/tech-kern/2000/03/14/0001.html
> > http://mail-index.netbsd.org/tech-kern/2000/03/20/0000.html
> 
> One thing to consider is that on platforms with much more physical
> memory than addressable virtual memory (cough, i386), pageable data
> doesn't really help you.  You'll run out of kernel VM long before
> physical memory.

that's why as many things as possible pageable is important.
aobj pages do not need to be mapped anywhere to retain their identity,
so a limited virtual address space doesn't cause any problem.


> If you make your filespace allocator use physical pages, you have
> the advantage of just keeping the physical page around without a
> virtual mapping.  There's nothing that prevents you from swapping
> these physical pages out yourself, but it would be nice if the
> system could that.  One thing to consider is that unlike normal
> VM usage, you don't have to worry about a page of file-data being
> double mapped into multiple files. This can simplify a design
> considerably.

an aobj does all of these things quite nicely already, including letting
pages be paged out to swap.


> The limitation of the tmpfs size should the amount in the system,
> not the amount of kernel VM space.

if what you meant was "amount of virtual memory (physical + swap)
in the system", then I certainly agree.

-Chuck