Satisfy page cache

[OrangeQi-CQ]

1. 给文件打开新增 direct 标志
2. 在 aspace 提供更多类型映射形式(map_file)
3. 给 MemoryArea 的 Backend 提供 File 类型

[Azure-stars]

We don't suggest to add a File Backend here, because Linear(linear mapping) and Alloc(dynamic mapping) are self-consistent enough to complete memory allocation related tasks, we do not want the module axmm in charge of memory to introduce file-related content.

[Azure-stars]

A possible solution is to check whether there is a file mapping interval covering the missing address in the handle_page_fault part of starry(see here) after completing the physical page allocation for the missing page. If so, check whether the content of the file needs to be written to the newly allocated physical page.

[Anekoique]

A possible solution is to check whether there is a file mapping interval covering the missing address in the handle_page_fault part of starry(see here) after completing the physical page allocation for the missing page. If so, check whether the content of the file needs to be written to the newly allocated physical page.

If we don't create a mapping from MemoryArea to file in axmm, we need to maintain this mapping in starry. Will this cost be too much? My idea is to create a vm_area_struct like Linux and maintain the mapping to the file and offset in MemoryArea. When we get vma during handle_page_fault, we can directly get this mapping. But this will introduce the file of starry in axmm. Do you have any good suggestions?

[Azure-stars]

A possible solution is to check whether there is a file mapping interval covering the missing address in the handle_page_fault part of starry(see here) after completing the physical page allocation for the missing page. If so, check whether the content of the file needs to be written to the newly allocated physical page.

If we don't create a mapping from MemoryArea to file in axmm, we need to maintain this mapping in starry. Will this cost be too much? My idea is to create a vm_area_struct like Linux and maintain the mapping to the file and offset in MemoryArea. When we get vma during handle_page_fault, we can directly get this mapping. But this will introduce the file of starry in axmm. Do you have any good suggestions?

One method we recommend is to maintain the mapping relationship between mmap area and file in ProcessData. For each process, it will consist of a batch of linear intervals, and there is no overlap between the intervals. Therefore, each time you query the file mapping relationship of the mmap area corresponding to a certain virtual address, you only need to traverse it linearly once. Its complexity is similar to find area

[Azure-stars]

Remove this line.

[Azure-stars]

Maybe we don't need to add this function?