[ros-kernel] AW: Re: Cache and memory manager

[Hartmut B. <har...@te...>]

Hi,

before we can implement a file cache like NT, we must solve some other problems:
1) There isn't a working system working set. The functions from mm/wset.c can only 
    handle working sets from other process's. They need a pointer to a process structure, 
    but the kernel hasn't a process structure. Some functions from device drivers and 
    ntoskrnl.exe are pageable. But gcc and ld can't split code to different code sections
    and mark some as non or pageable.
2) The working set doesn't include all the memory of a process. Memory, that is 
    used in section views or memory mapped file, isn't included in the working set.
3) It exist no working set manager. There is only an implemention for trimming of 
    working sets, that will start when MmAllocPage() can't grab a free page. But when 
    memory is write to the pagefile, than the kernel needs some free pages.
4) The access to the pagefile dosn't work. Some functions are commented out and 
    there are some bugs in allocation of free space in a pageing file.
5) The pte's and ppte's can't handle swap entries for a pageing file.

For implementation of the cache manager and some of the functions above, 
I have moved the code, which will access the cache segments, from vfatfs to 
some Cc-functions. Currently I work at point 4 and 5 and will correct some things 
in the page out and access violation functions for virtual memory.

Sorry for my bad english.

- Hartmut
   
> -----Ursprungliche Nachricht-----
> Von:	Phillip Susi [SMTP:ps...@cf...]
> Gesendet am:	Montag, 15. Oktober 2001 20:37
> An:	ros...@re...
> Betreff:	[ros-kernel] Re: Cache and memory manager
> 
> 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         =
> ====================================================

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