diff options
| author | Alex Auvolat <alex@adnab.me> | 2015-03-09 22:06:59 +0100 |
|---|---|---|
| committer | Alex Auvolat <alex@adnab.me> | 2015-03-09 22:06:59 +0100 |
| commit | e499d74b6f0b57f9a11486c346dbc335e4f8433d (patch) | |
| tree | 91c35db2d0edc5147f874f5f36c51eca8dd7cdb3 /README.md | |
| parent | 380fd19521dd5205ef3da5248899244b5b29dc27 (diff) | |
| download | kogata-e499d74b6f0b57f9a11486c346dbc335e4f8433d.tar.gz kogata-e499d74b6f0b57f9a11486c346dbc335e4f8433d.zip | |
Update README
Diffstat (limited to 'README.md')
| -rw-r--r-- | README.md | 13 |
1 files changed, 1 insertions, 12 deletions
@@ -116,18 +116,6 @@ running the tests): ### Things to design -* Cache architecture : - - A RAM file is basically a bunch of pages that contain the data (rather than a segment of - malloc()'ed memory) - - A framebuffer device is basically a bunch of pages at a fixed hardware location, that cannot - grow - - In the two previous cases, the pages are never freed : they are not a cache, they are the - data itself. - - In the case of an on-disk file, the pages are a copy of the file's data that is originally - on-disk, and we might want to free these pages even while a process is using them, because - we can always reload them from the disk. - - An on-disk file with a page cache must be aware of all the places where the page is mapped, - so that it can unmap it when reclaiming pages. * Reclaiming physical memory : - Freeing some cached stuff, ie swapping pages from mmap regions - Swapping pages from processes non-mmap regions (ie real data regions) @@ -142,6 +130,7 @@ running the tests): ### Things not sure * VFS thread safety : is the design correct ? (probably) +* Cache architecture (called *pager*, after 4.4BSD terminology) * Not enough tests! ### Plans for the later future |