An EFI script designed to disable defective memory regions before booting macOS, allowing macOS to work again on systems with faulty memory. For users experiencing memory-related issues on Apple MacBooks and Macs, offering a software-based solution to avoid costly hardware repairs.
0
stars
0
forks
source link
FEAT: Read output of memory test and generate map of bad mem to be reserved from the OS #2
Pretty self explanatory, take the output of a memory test process (see 0nelight/macOS-Disable-RAM-Areas#11 / #1) and generate the memory reserve table. However, this raises an interesting conundrum.
I believe that the more ranges are reserved, i.e. the more reserved page ranges in /proc/iomem, the more space it's going to take up in the OS page tables. This shouldn't be too much of a issue when we have, say, 100 ranges, but if we tried to reserve 100,000 pages of size 1 page each, I'm not sure how well each OS is going to handle that.
Fortunately, I think the TLB should remain mostly unaffected, as these are literally pages that aren't referenced, so while it is possible that the boot process might suffer by at most a few milliseconds because of a large number of pages already in the TLB from the reservation process, they should get flushed relatively quickly, bringing the TLB cache misses down to normal levels within a few seconds at most. However, I would really rather not create potential weird performance problems for anyone using this utility, so a few large ranges of addresses are "better" than many very small ranges.
But at the same time, the extreme of reserving the entire block from the first memory address to the last is also not ideal in many cases. If a machine with 64GiB of ram only had two problem addresses, at 0x0000_0001_002A_17ED at 0x0000_000F_61F7_1AE1, reserving this as a single range would block off over 57 GiB, leaving slightly under 7 GiB. Blocking off 90% of memory to prevent access to 8KiB of RAM that shouldn't be used isn't the right approach, so several small ranges are "better" than a single large range.
These two concerns point to a need to figure out how to set a general "strategy" for how many ranges to reserve, and how large they should be.
Pretty self explanatory, take the output of a memory test process (see 0nelight/macOS-Disable-RAM-Areas#11 / #1) and generate the memory reserve table. However, this raises an interesting conundrum.
I believe that the more ranges are reserved, i.e. the more reserved page ranges in /proc/iomem, the more space it's going to take up in the OS page tables. This shouldn't be too much of a issue when we have, say, 100 ranges, but if we tried to reserve 100,000 pages of size 1 page each, I'm not sure how well each OS is going to handle that.
Fortunately, I think the TLB should remain mostly unaffected, as these are literally pages that aren't referenced, so while it is possible that the boot process might suffer by at most a few milliseconds because of a large number of pages already in the TLB from the reservation process, they should get flushed relatively quickly, bringing the TLB cache misses down to normal levels within a few seconds at most. However, I would really rather not create potential weird performance problems for anyone using this utility, so a few large ranges of addresses are "better" than many very small ranges.
But at the same time, the extreme of reserving the entire block from the first memory address to the last is also not ideal in many cases. If a machine with 64GiB of ram only had two problem addresses, at 0x0000_0001_002A_17ED at 0x0000_000F_61F7_1AE1, reserving this as a single range would block off over 57 GiB, leaving slightly under 7 GiB. Blocking off 90% of memory to prevent access to 8KiB of RAM that shouldn't be used isn't the right approach, so several small ranges are "better" than a single large range.
These two concerns point to a need to figure out how to set a general "strategy" for how many ranges to reserve, and how large they should be.