OSDev.org

The Place to Start for Operating System Developers
It is currently Sat Sep 26, 2020 9:44 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 3 posts ] 
Author Message
 Post subject: [Solved] Keeping shared memory in-sync
PostPosted: Sat Jul 04, 2020 5:55 am 
Offline
Member
Member

Joined: Fri May 20, 2016 2:29 pm
Posts: 42
Location: Paris, France
Hello!

I'm in the process of rewriting my virtual memory manager and have run into a hang-up.

Each address space is composed of a page-directory and a bitmap describing allocated pages. Each address-space shares the page tables that identity-map low memory, kernel data+code, kernel ELF sections, etc. Memory is allocated on a first-fit basis, so it's reasonable for an allocation to be fulfilled in a globally shared page table.

If a process allocates memory within one of these globally-shared-tables, then every process will then receive the updated state in the shared page tables. However, only the process that fulfilled the allocation would have the memory marked in its allocation bitmap.

I was banging my head against this for a few days after seeing mismatched states between a process's page-tables and allocation bitmap until I realized what was going on. For now, on task switch, I iterate the shared tables and ensure nothing is out-of-sync, and panic if it is.

I'm trying to come up with a clean way to signal allocations to a shared table, so that every process that shares the table can mark the pages as allocated in its bitmap. A few ideas:

- Each VAS never allocates memory within a shared table unless specifically requested. This seems like punting the problem until future-me needs some shared buffer between processes.

- Within the shared kernel memory, maintain a linked-list of VAS's that refer to shared page tables. Whenever an allocation is fulfilled within a shared page table, iterate each VAS, map in the VAS structure somewhere, and update its allocation bitmap. This seems to require quite a lot of state about which page tables are shared by which VAS. This update could alternatively be performed on a task switch, or when a mismatched allocation state is detected between the page tables and allocation bitmap.

- Within the shared kernel memory, maintain a pointer to the "latest" VAS containing modifications to the shared kernel tables. When an allocation is fulfilled in a shared page table, update the pointer to the VAS that fulfilled the allocation. On task switch (or w/e), update the allocation state to match that of the "latest" VAS's shared tables. This seems fine, but seems to be special-casing the shared kernel memory. It'd be nice if the approach worked for general-purpose IPC shared-memory.

I'm sure this is trod-ground and am curious if anyone has an approach they can share. Thanks!

_________________
www.github.com/codyd51/axle.git


Last edited by codyd51 on Sat Jul 04, 2020 4:58 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject: Re: Keeping shared memory in-sync
PostPosted: Sat Jul 04, 2020 6:20 am 
Offline
Member
Member

Joined: Tue Apr 03, 2018 2:44 am
Posts: 60
codyd51 wrote:
Hello!

I'm in the process of rewriting my virtual memory manager and have run into a hang-up.

Each address space is composed of a page-directory and a bitmap describing allocated pages. Each address-space shares the page tables that identity-map low memory, kernel data+code, kernel ELF sections, etc. Memory is allocated on a first-fit basis, so it's reasonable for an allocation to be fulfilled in a globally shared page table.

If a process allocates memory within one of these globally-shared-tables, then every process will then receive the updated state in the shared page tables. However, only the process that fulfilled the allocation would have the memory marked in its allocation bitmap.

I was banging my head against this for a few days after seeing mismatched states between a process's page-tables and allocation bitmap until I realized what was going on. For now, on task switch, I iterate the shared tables and ensure nothing is out-of-sync, and panic if it is.

I'm trying to come up with a clean way to signal allocations to a shared table, so that every process that shares the table can mark the pages as allocated in its bitmap. A few ideas:


If you have shared tables in kernel space, why bother tracking those per-process?

Instead, use your per-process bitmap purely per process user mapping, and perhaps have a shared bitmap for kernel mappings. That way, you just need to manage a single shared bitmap, but you will have to partition your bitmap handling between user and kernel mappings.


Top
 Profile  
 
 Post subject: Re: Keeping shared memory in-sync
PostPosted: Sat Jul 04, 2020 5:05 pm 
Offline
Member
Member

Joined: Fri May 20, 2016 2:29 pm
Posts: 42
Location: Paris, France
thewrongchristian wrote:
Instead, use your per-process bitmap purely per process user mapping, and perhaps have a shared bitmap for kernel mappings.


This is a really good idea! I tried it out, and it works nicely. I've marked this post as solved. Thanks for the thought-time :D

I'll need to watch out for a few things, like an allocation crossing over from the shared-mapping into a unique-mapping, and being careful when to allocate in each map, but it's all solvable in a straightforward way.

Code:
static address_space_page_bitmap_t* _vmm_bitmap_for_addr(vmm_page_directory_t* vmm_dir, uint32_t page_addr) {
    if (page_addr < _first_page_outside_shared_kernel_tables) {
        return _vmm_state_bitmap(boot_info_get()->vmm_kernel);
    }
    return _vmm_state_bitmap(vmm_dir);
}

_________________
www.github.com/codyd51/axle.git


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 3 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group