paging: make ALL levels writable, not just P4

[zyuiop]

After investigating PF exceptions, I traced them back to a pt.set_unused() call, which failed because the page table was not entirely writable.

[fogti]

Does this work correctly in the presence of reserved (by boot-loader) read-only memory?

[github-actions]

Benchmark Results

Details

Benchmark	Current: b46fc5d	Previous: f017c04	Performance Ratio
startup_benchmark Build Time	98.91 s	100.00 s	0.99 ❗
startup_benchmark File Size	0.86 MB	0.86 MB	1.00 ❗
Startup Time - 1 core	0.93 s (±0.03 s)	0.96 s (±0.03 s)	0.97
Startup Time - 2 cores	0.95 s (±0.03 s)	0.96 s (±0.03 s)	0.99
Startup Time - 4 cores	0.94 s (±0.03 s)	0.96 s (±0.03 s)	0.98
multithreaded_benchmark Build Time	100.47 s	101.55 s	0.99 ❗
multithreaded_benchmark File Size	0.96 MB	0.96 MB	1.00 ❗
Multithreaded Pi Efficiency - 2 Threads	91.19 % (±8.48 %)	88.90 % (±8.32 %)	1.03
Multithreaded Pi Efficiency - 4 Threads	43.95 % (±3.61 %)	43.88 % (±2.75 %)	1.00
Multithreaded Pi Efficiency - 8 Threads	25.75 % (±1.89 %)	25.66 % (±1.89 %)	1.00
micro_benchmarks Build Time	95.09 s	100.99 s	0.94 ❗
micro_benchmarks File Size	0.97 MB	0.97 MB	1.00 ❗
Scheduling time - 1 thread	67.01 ticks (±3.71 ticks)	69.86 ticks (±3.37 ticks)	0.96
Scheduling time - 2 threads	38.86 ticks (±5.68 ticks)	40.31 ticks (±6.77 ticks)	0.96
Micro - Time for syscall (getpid)	3.92 ticks (±0.41 ticks)	3.96 ticks (±0.50 ticks)	0.99
Memcpy speed - (built_in) block size 4096	67239.64 MByte/s (±47785.51 MByte/s)	65275.34 MByte/s (±46520.56 MByte/s)	1.03
Memcpy speed - (built_in) block size 1048576	29668.49 MByte/s (±24208.03 MByte/s)	29541.10 MByte/s (±24264.88 MByte/s)	1.00
Memcpy speed - (built_in) block size 16777216	28524.40 MByte/s (±23715.64 MByte/s)	24775.73 MByte/s (±20842.74 MByte/s)	1.15
Memset speed - (built_in) block size 4096	68250.71 MByte/s (±48513.16 MByte/s)	66091.92 MByte/s (±47089.66 MByte/s)	1.03
Memset speed - (built_in) block size 1048576	30423.69 MByte/s (±24628.09 MByte/s)	30293.21 MByte/s (±24687.70 MByte/s)	1.00
Memset speed - (built_in) block size 16777216	29290.73 MByte/s (±24148.29 MByte/s)	25550.97 MByte/s (±21347.58 MByte/s)	1.15
Memcpy speed - (rust) block size 4096	60931.32 MByte/s (±44862.89 MByte/s)	58754.84 MByte/s (±43359.45 MByte/s)	1.04
Memcpy speed - (rust) block size 1048576	29394.50 MByte/s (±24111.70 MByte/s)	29244.90 MByte/s (±24125.53 MByte/s)	1.01
Memcpy speed - (rust) block size 16777216	28529.04 MByte/s (±23725.01 MByte/s)	25398.03 MByte/s (±21360.45 MByte/s)	1.12
Memset speed - (rust) block size 4096	61741.04 MByte/s (±45345.78 MByte/s)	59191.17 MByte/s (±43611.85 MByte/s)	1.04
Memset speed - (rust) block size 1048576	30147.72 MByte/s (±24536.09 MByte/s)	29995.68 MByte/s (±24557.30 MByte/s)	1.01
Memset speed - (rust) block size 16777216	29284.98 MByte/s (±24148.89 MByte/s)	26167.61 MByte/s (±21843.64 MByte/s)	1.12
alloc_benchmarks Build Time	92.89 s	99.83 s	0.93 ❗
alloc_benchmarks File Size	0.94 MB	0.93 MB	1.00 ❗
Allocations - Allocation success	100.00 %	100.00 %	1
Allocations - Deallocation success	100.00 %	100.00 %	1
Allocations - Pre-fail Allocations	100.00 %	100.00 %	1
Allocations - Average Allocation time	9455.00 Ticks (±161.71 Ticks)	9424.02 Ticks (±112.49 Ticks)	1.00
Allocations - Average Allocation time (no fail)	9455.00 Ticks (±161.71 Ticks)	9424.02 Ticks (±112.49 Ticks)	1.00
Allocations - Average Deallocation time	1848.79 Ticks (±500.69 Ticks)	1052.94 Ticks (±452.14 Ticks)	1.76 ❗
mutex_benchmark Build Time	96.90 s	99.82 s	0.97 ❗
mutex_benchmark File Size	0.97 MB	0.97 MB	1.00 ❗
Mutex Stress Test Average Time per Iteration - 1 Threads	13.22 ns (±0.64 ns)	13.02 ns (±0.55 ns)	1.02
Mutex Stress Test Average Time per Iteration - 2 Threads	13.80 ns (±0.80 ns)	13.62 ns (±0.77 ns)	1.01

This comment was automatically generated by workflow using github-action-benchmark.

[fogti]

Wait, is the title of this PR misleading and this does make all levels including-and-below P4 writable, but doesn't touch anything else?

[zyuiop]

Does this work correctly in the presence of reserved (by boot-loader) read-only memory?

Not sure. I think the best fix would be to remap memory and not reuse the boot-loader mapping, or at least use an offset map for accessing page tables, as currently it is a bit weird.

[mkroening]

I think the best fix would be to remap memory and not reuse the boot-loader mapping, or at least use an offset map for accessing page tables, as currently it is a bit weird.

I agree. I was planning to do this anyway with the next loader release. This PR is still useful for you in the meantime, right?

[mkroening]

Wait, is the title of this PR misleading and this does make all levels including-and-below P4 writable, but doesn't touch anything else?

How is the title misleading?

[zyuiop]

This PR is still useful for you in the meantime, right?

I have it in my fork as well, so it's okay!

[fogti]

I did say what I find misleading in the rest of the sentence, what information is still missing?

[mkroening]

I did say what I find misleading in the rest of the sentence, what information is still missing?

This PR is about making more of the page table writable. This is not about actually writing to any reserved memory or marking the memory as available in our physical memory management structures.

Is it clearer now? "This does make all levels including-and-below P4 writable, but doesn't touch anything else" sounds the same as the title to me, so I am confused about what you mean.

In any case, let's see how quickly the loader is progressing. We can keep the PR open until it is resolved. In case we find any issues with the plan, we can merge it.