Page 1 of 1

Virtual memory remap with different sizes

Posted: Wed Oct 08, 2025 2:03 am
by tretornesp
Hello there,

I'm reviewing some of the design choices I took in past projects and one of the biggest doubts that
I have is how to handle page overlap. A simplified example:

1. The kernel maps vaddr 0xFF0200000 with a page size of 4KB. The valid range would be (0xFF0200000 - 0xFF0200FFF)
2. The kernel now maps vaddr 0xFF0200000 with a page size of 2MB. The valid range would be (0xFF0200000 - 0xFF03FFFFF)

You can clearly see that the ranges overlap. This is also true in case steps 1 and 2 get inverted. Even worse, the smaller range
doesn't have to start in the same address as the bigger one (0xFF0204000-0xFF0204FFF)...

In your opinion ¿How should this kind of situations be addressed?

My current approach is to respect the biggest mapping and if in a tie, respect the newer mapping.

Im eager to hear your opinion :D

Have a great day!

Re: Virtual memory remap with different sizes

Posted: Wed Oct 08, 2025 8:45 am
by iansjack
How can you map the same virtual address with different page sizes?

Re: Virtual memory remap with different sizes

Posted: Sat Oct 11, 2025 1:05 pm
by Gigasoft
The most sensible thing to do is, if a driver requests to map a large page where smaller pages were previously assigned, the previous page tables should be discarded. Similarly, if a large page was mapped and a driver requests to map a small page, the large page should be replaced with a new, empty page table, just as if nothing was previously mapped.

As for virtual address allocations, those should never overlap. If something requests to reserve a specific address range that is already allocated, the operation should fail.

Re: Virtual memory remap with different sizes

Posted: Wed Oct 15, 2025 2:40 am
by rdos
I think the most sensible thing is not to allow this. If pages with 4k alignment have already been allocated in some area, then this area clearly cannot be allocated as a 2M area since it is not free. My 2M allocator checks so all pages in the 2M region are free, and if not, searches in other regions.

Re: Virtual memory remap with different sizes

Posted: Wed Oct 15, 2025 10:02 am
by sebihepp
Is there any benefit for mixing 4KiB and 2MiB pages other than page tables using less memory?

Re: Virtual memory remap with different sizes

Posted: Wed Oct 15, 2025 12:48 pm
by Demindiro
At least in Linux userspace, mmap() simply replaces any ranges that may have already been mapped. I'd do the same in kernel space, as I see little reason to make it more complicated than that (why involve page size anyway?).

If the concern is that you need to split up the 2M page: just split it into 4K pages?

Returning an error on overlap is also a possibility, depending on what your needs are. Or add a flag to select between the two behaviors.
sebihepp wrote: Wed Oct 15, 2025 10:02 am Is there any benefit for mixing 4KiB and 2MiB pages other than page tables using less memory?
Larger pages reduce TLB pressure.

Re: Virtual memory remap with different sizes

Posted: Wed Oct 15, 2025 1:11 pm
by nullplan
Speaking of Linux, its page table manip code doesn't have a way to merge pages into a higher size class. Only to smash larger pages as might be necessary. So I'm going to guess that trying to do that is just not worth it.

Re: Virtual memory remap with different sizes

Posted: Mon Feb 23, 2026 9:07 am
by ccya
虚拟地址不可能会重叠,或许在你的眼里2MB之下还有4KB的内存页与他上面的2MB内存页重叠了,这很符合人类直觉但在处理器眼里他永远也不会重叠,来让我们看看处理器是怎样读取物理地址的,他首先会从顶层页表开始读取,如果你使用的是1GB页大小那他将立刻停止读取下面的任何内容了,如果你用的是2MB页大小那他将会继续读取你的2MB页表然后立刻停止,听起来很复杂但你只需要知道2MB页表在4KB页表之上,任何在此范围内的读写操作都会被2MB页表拦截,你那4KB的重叠地址根本就不会被使用,你只是在杞人忧天。

Re: Virtual memory remap with different sizes

Posted: Mon Feb 23, 2026 12:06 pm
by nullplan
ccya wrote: Mon Feb 23, 2026 9:07 am 虚拟地址不可能会重叠,或许在你的眼里2MB之下还有4KB的内存页与他上面的2MB内存页重叠了,这很符合人类直觉但在处理器眼里他永远也不会重叠,来让我们看看处理器是怎样读取物理地址的,他首先会从顶层页表开始读取,如果你使用的是1GB页大小那他将立刻停止读取下面的任何内容了,如果你用的是2MB页大小那他将会继续读取你的2MB页表然后立刻停止,听起来很复杂但你只需要知道2MB页表在4KB页表之上,任何在此范围内的读写操作都会被2MB页表拦截,你那4KB的重叠地址根本就不会被使用,你只是在杞人忧天。
Forum language is English. Please try to use it, at least. I mean, OK, deepl exists, but then you can just paste its output into the post box.

Beyond that, nobody contested any of what you posted. The question was what to do if one driver requests a 2MB page in a place where 4kB pages already exist. And of course, I think the normal conflict resolution should apply here. There can be only one mapping for a given address, so either the old or the new requests get to win. If the old requests win, the new request is denied, and if the new request wins, the old ones are discarded.