Page MenuHomeFreeBSD

Remove sv_pagesize.
ClosedPublic

Authored by trasz on Feb 21 2019, 3:04 PM.
Tags
None
Referenced Files
Unknown Object (File)
Oct 2 2024, 6:51 AM
Unknown Object (File)
Sep 22 2024, 5:25 PM
Unknown Object (File)
Sep 19 2024, 5:29 PM
Unknown Object (File)
Sep 18 2024, 7:45 PM
Unknown Object (File)
Sep 17 2024, 5:51 PM
Unknown Object (File)
Sep 17 2024, 6:29 AM
Unknown Object (File)
Sep 16 2024, 10:15 PM
Unknown Object (File)
Sep 15 2024, 3:33 PM

Details

Summary

Remove sv_pagesize, introduced in r100384. Nowadays it serves no purpose and clutters the code. There should be no functional changes.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 22640
Build 21747: arc lint + arc unit

Event Timeline

Link to the change in Phab's repo viewer: rS100384

I agree this is good today.

There's a few reasons we had this in the past...

First, there was the fear that IA32_PAGE_SIZE != PAGE_SIZE on some architecture where that's relevant. I don't know about ia64, but amd64 has the same definition. ia64 was removed, so it doesn't matter.

Next, if we have one architecture that could run binaries from another. This is the general case of 1. The one with most relevance after i386 on amd64 is arm binaries on arm64. In that case, the page size is the same, so it wouldn't matter. MIPS has multiple page sizes in hardware, for example. Plus there's multiple ways to model MIPS's lo/hi split in the TLB. One could, in theory, have 4k or 8k page sizes (that were relevant to the loader, being the unit rounded to, which is why this matters at all). These systems did exist in the wild in the 1990s, but we don't support binaries from them and likely never will. So the exotic binary reason we had in place seems to in practice not be necessary.

Finally, we might need something like this if we were to try to support a new, larger page size on arm64 or amd64. There's been some evidence, though it's weak, that this would help things. The theory here is that we'd use larger, more contiguous pages. The jury is still out on this, though signs are so weak that it's hard to say there's a good chance they'd come back and say "we need this." Since this is the most speculative and theoretical of them all, and since it's not on the horizon, the remote possibility of this happening likely isn't doesn't justify keeping it. Should it become the case in the future, we can always revisit if this is the right vector for that support.

So having said all that, I'd be tempted to soften your commit message with something like:

In all of the architectures we have today, we always use PAGE_SIZE. While in theory one could define different things, none of the current architectures do, even the ones that have transitioned from 32-bit to 64-bit like i386 and arm. Some ancient mips binaries on other systems used 8k instead of 4k, but we don't support running those and likely never will due to their age and obscurity.

since that will provide just enough extra context that future readers of the commit will understand, as well as show that a careful audit was made and all relevant factors were considered. But in the end, it's up to you to decide if this improves things or not.

This revision is now accepted and ready to land.Feb 21 2019, 4:54 PM

Interested in @andrew's insight

I've talked to Andrew, it doesn't seem related to aarch64's 64k pages.

This revision was automatically updated to reflect the committed changes.