Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
syscall: Getpagesize should return actual system value on Solaris #12558
As noted in #12076 Getpagesize doesn't currently return the actual system's default page size, but rather a hard-coded value. Per the discussion with @ianlancetaylor on golang-dev , the opinion was that syscall.Getpagesize should return the same value as the POSIX call sysconf(_SC_PAGESIZE).
This change will be necessary for future platform support on Solaris.
While this change could be generally applied (more than likely) to all other POSIX platforms, I'm only planning on making this change for Solaris for now.
This issue is being filed to track the change against golang/go separately from x/sys/unix.
While it may be viewed as related to #10180, I believe it can be resolved independently.
Like I said, I'm going off what Ian told me, so I'll let all of you work things out.
For the record though, if the runtime does not return the same pagesize as what sysconf(_SC_PAGESIZE) returns, that's going to be a problem too.
I agree, this is fine for x/sys/unix, but for syscall is not the right thing. It has to involve the runtime, and it's not just making the runtime call this function either. Unfortunately, the runtime doesn't work well with big page sizes. We should fix #10180, plus any other bugs that linger in the runtime, like #9993 and #11933 (some of them have been fixed, but they're just symptoms of a larger problem).
In particular, we need to make the runtime work with multiple dynamic page sizes.
@4ad on Solaris, the runtime may not have a choice about whether or not big pages are used. In particular, on SPARC systems, much larger page sizes may be used by default as very large SPARC systems are already at a max of 32 terabytes of memory and I imagine that will increase in the future.
If this change should not be made for syscall today, should I close this issue as a duplicate of #10180 then?