reactos-kernel

[ros-kernel] Re: Cache and memory manager

[<we...@cw...>]

Philip Susi writes
>
>It is more difficult to create and maintain all of these special code
>paths and algorithms for the cache than it would be to simply let the
>existing memory management code do all the work for you like in NT.
>
But the existing memory management code doesn't 'do all the work'
since cached file data and memory mapped files are fundamentally
different things. Most of the time data will either be memory mapped
or the subject of NtReadFile/NtWriteFile and we want the paths for
handling both to be optimized for their specific characteristics not
to kludge one into a special case of the other.

>We do?  Where? 
>
Because every time an application uses a part of a cached file
then it calls (via the filesystem) the cache manager so we can record the
LRU information very easily.

> And how does memory mapped files interact with this cache?
>
My plan was to handle memory mapped data which is also shared
with the cache using the mechanism for paging user data.

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================

[ros-kernel] Re: Cache and memory manager

[Phillip S. <ps...@cf...>]

At 03:50 PM 10/15/2001 +0100, you wrote:
>But the existing memory management code doesn't 'do all the work'

Yes it does:  it handles memory mapped files ( sections ) and working 
sets.  These are all that are needed to implement the cache.

>since cached file data and memory mapped files are fundamentally
>different things. Most of the time data will either be memory mapped

How are they different?  They are both just file data in memory.  The only 
difference is semantics:  is memory allocated, and then have file data read 
into it, or is it mapped, and the data is read in on page fault or 
otherwise locking of the memory.

>or the subject of NtReadFile/NtWriteFile and we want the paths for
>handling both to be optimized for their specific characteristics not
>to kludge one into a special case of the other.

What is a kludge here?  NtReadFile needs to return some data to the caller, 
it is already mapped into the kernel address space for caching, just do 
memcpy().


>Because every time an application uses a part of a cached file
>then it calls (via the filesystem) the cache manager so we can record the
>LRU information very easily.

Only when it uses it via Read/Write calls, not via MMF.


> > And how does memory mapped files interact with this cache?
> >
>My plan was to handle memory mapped data which is also shared
>with the cache using the mechanism for paging user data.

This is precisely the way that NT does it by utilizing the same section 
object for both the cache and MMF, and the main reason I like the idea:  it 
uses the same system for cache and MMF, keeping things simple and 
unified.  Am I confused, or are you not planning on using the section 
object for the cache?  If you are not, how is the cache and MMF to share 
the same pages?  It seems to me that your plan calls for section objects 
and MMF to be totally different than the cache block structure.

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================