Replace mem.page_size with mem.min_page_size and mem.max_page_size

[andrewrk]

Quoting @daurnimator from #3815:

This PR removes mem.page_size and replaces it with minimums and maximums. Originally I attempted to create a global variable page_size, but I realised that this would not work when zig's own startup routines are not used (e.g. when zig is used to create a static library). There is no linux syscall to get the current page size if you don't have access to the auxiliary vector, so a hacky solution would be required (e.g. using the knowledge that madvise returns EINVAL on non-page aligned arguments, and doing a search for the page size)

This PR introduces mem.bufsiz as a reasonable "default size" for buffers. The name is taken from the posix constant BUFSIZ.

Additionally, on linux we now assert that the page size in the auxiliary vector matches expectations.

This proposal solves #2564

[mikdusan]

how about:

// page_sizes.len is guaranteed  > 0
// page_sizes guaranteed in order smallest to largest
// "max" and "min" is page_sizes[0] and page_sizes[page_sizes.len-1] 

// on arm with 4 page sizes
const page_sizes: []const usize = [_]usize{ 0x1000, 0x10000, 0x100000, 0x1000000 }; // 4K, 65K, 1M, 1G

// a default is always needed could be comptime set to something other than smallest
const default_page_size = page_sizes[0];

posix BUFSIZ is for io and doesn't belong in std.mem . Maybe std.io.bufsiz. For example, when working with pathnames and naturally using std.mem functions, I don't want to use BUFSIZ.

[dkwo]

What is the status of this proposal?
Would it fix the wrong page size for Linux on Apple Silicon?

[nektro]

no the linked issue explains that page_size needs to become a runtime value for that to work properly

[andrewrk]

Along with the original proposal I am tagging along this change as well:

• move it from std.mem to std.heap.

[Parzival-3141]

Taking a swing at this but I have a couple questions.

• Is the original proposal accepted as is? Is bufsiz included as well?
• What about @mikdusan's proposal? Seems wise to offer more information to users.
• Should be page size info be part of the target os/arch instead?

I'm leaning more towards @mikdusan and this comment's ideas.

[matu3ba]

Additionally, on linux we now assert that the page size in the auxiliary vector matches expectations.

I wonder, where those expectations come from. Kernels provide the default size and, if available, a user-configurable size for large pages and one needs Kernel or CPU-level privilege to do stuff in the MMU etc.

I would propose instead a 1. portable large table abstraction (which are unfortunately named different in different Kernels), 2. making possible page sizes from the hardware available at comptime and 3. provide probing functionality for such large page abstractions.

Background: One can configure or compile Kernels with different page size support and not all Kernels provide the page API: Hermit has no reliable page size and neither an api for it. See hermit-os/kernel#815.
If one wants to take them into account in a portable way (cross-compiling etc), one has to do runtime probing.