Re: Review of Thomas's >2GB ext2fs proposal

[Thomas Bushnell BSG]

"Neal H. Walfield" <neal@cs.uml.edu> writes:

> Interesting.  But can't we do this already?  Instead of using
> store_read and store_write in pager code, we need only use store_map
> to get a memory object to the disk.  Then when we get a page in
> request, we do a vm_map on the supplied memory object and return that
> to Mach.

If you try that, the kernel always copies the page.  Pages are not
allowed to exist in multiple memory objects at once; this is a fairly
fundamental consequence of the way Mach implements pagers and handles
memory management.

You end up with the same data living in two pages, taking up double
memory.  Every page of disk should live in only one pager at a time,
for optimal performance.

> There must be a misunderstanding here.  I have gone to great lengths
> to make use that the mapping cache is perfectly harmonized with Mach's
> paging strategy; in fact, I rely nearly completely on Mach's to make
> any mapping eviction.

I understand this now, thanks to the explanation in the other thread;
though I have some more questions there too.

> > By contrast, mine also requires a caching strategy, but it is only a
> > caching strategy for memory mappings, which, unlike core, are not a
> > limited globally shared resource.
> 
> But what is your caching strategy?  My caching strategy has only
> previous pages as its overhead.  It is completely synchronized with
> Mach's eviction scheme.  What is yours?

I only cache mappings, so it doesn't really matter.  Creating mappings
is very very cheap (especially if you allow Mach to pick the addresses
by using the anywhere flag).  Creating mappings is just vm_map, which
is speedy and quick--it's the same as vm_allocate.  But I would use
LRU for lack of something else.

Mappings carry no overhead, and are quick and easy to set up and tear
down. 

Thomas