OSDev.org

Hi everyone,

I am currently porting my abstraction layer from 64bits to 32bits architecture and I would like to avoid recursive mapping when it comes to memory management.
On 64bits it was easy as I limit my OS to 512GB of memory support so I was just mapping the whole available physical memory in my kernel. Managing other processes memory in that case was easy.

However, in 32bits I always used recursive mapping and I was panning to simply temporary map memory when managing other's processes memory and then unmapping it when I was done.
But I feel like I am missing something and that something more clever could be done. What would you recommend?

Thanks!

Oxmose wrote: ↑Mon Oct 21, 2024 9:27 amOn 64bits it was easy as I limit my OS to 512GB of memory support so I was just mapping the whole available physical memory in my kernel.

Why only 512GB?

Oxmose wrote: ↑Mon Oct 21, 2024 9:27 amBut I feel like I am missing something and that something more clever could be done.

The only thing I can think of that you haven't mentioned is assigning a specific address to each CPU's temporary mapping, and you might already be planning to do that anyway. Since each CPU will only access its own mapping, you don't need to worry about flushing any other CPU's TLB when the temporary mapping changes.

There's also the option of switching to a page table that uses the entire virtual address space to map all physical memory, but the TLB overhead is worse than a small temporary mapping, and you can't map all physical memory when the CPU has more than 32 physical address bits.

Octocontrabass wrote: ↑Mon Oct 21, 2024 11:38 am Why only 512GB?

For the moment I just choose to use one entry in the page directory to linear map all memory. But I guess I could more. I leave the low-half canonical space for the user and the high-half for the kernel. However the kernel only uses the last 2GB of this space. Thus I could go up to 128TB - 2GB. But I am not interested into implementing that at the moment.

Octocontrabass wrote: ↑Mon Oct 21, 2024 11:38 am The only thing I can think of that you haven't mentioned is assigning a specific address to each CPU's temporary mapping, and you might already be planning to do that anyway. Since each CPU will only access its own mapping, you don't need to worry about flushing any other CPU's TLB when the temporary mapping changes.

Yes each CPU has a range of addresses for temporary mapping. I allow myself to up to 2MB of temporary mapping to lower the overhead when copying huge blocks of memory, while keeping the address range reservation overhead low. 2MB was arbitrary (based on a previous project or mine) and might be too big?

Octocontrabass wrote: ↑Mon Oct 21, 2024 11:38 am There's also the option of switching to a page table that uses the entire virtual address space to map all physical memory, but the TLB overhead is worse than a small temporary mapping, and you can't map all physical memory when the CPU has more than 32 physical address bits.

Yeah same, I am not a fan of this option. But I feel like recursive mapping for 32bits is still a good approach in the end, due to the lack of better alternative.

Thank you!