Get the SuperPage size
It appears that some BSD systems have a superpage size of 2MB while others have 4MB. I've not seen any others. Is there any way to tell what the available superpage size is? Ideally from the command line, and without having to enable them.
osx freebsd virtual-memory
asked Feb 12 at 17:53
OrangeDogOrangeDog
432210
add a comment |
It appears that some BSD systems have a superpage size of 2MB while others have 4MB. I've not seen any others. Is there any way to tell what the available superpage size is? Ideally from the command line, and without having to enable them.
osx freebsd virtual-memory
asked Feb 12 at 17:53
OrangeDogOrangeDog
432210
add a comment |
It appears that some BSD systems have a superpage size of 2MB while others have 4MB. I've not seen any others. Is there any way to tell what the available superpage size is? Ideally from the command line, and without having to enable them.
osx freebsd virtual-memory
asked Feb 12 at 17:53
OrangeDogOrangeDog
432210
It appears that some BSD systems have a superpage size of 2MB while others have 4MB. I've not seen any others. Is there any way to tell what the available superpage size is? Ideally from the command line, and without having to enable them.
osx freebsd virtual-memory
osx freebsd virtual-memory
asked Feb 12 at 17:53
OrangeDogOrangeDog
432210
asked Feb 12 at 17:53
OrangeDogOrangeDog
432210
asked Feb 12 at 17:53
OrangeDogOrangeDog
432210
asked Feb 12 at 17:53
OrangeDogOrangeDog
432210
asked Feb 12 at 17:53
OrangeDogOrangeDog
432210
432210
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Alan L. Cox made some interesting Opteron benchmarks and was co-author of the original superpage paper (presented at Usenix 2002): Practical, transparent operating system support for superpages
Superpages was introduced in 2013 for FreeBSD 7.2 for amd64 and i386
[amd64, i386] The FreeBSD virtual memory subsystem now supports fully transparent use of superpages for application memory;
application memory pages are dynamically promoted to or demoted from superpages without any modification to application code.
This change offers the benefit of large page sizes such as improved virtual memory efficiency
and reduced TLB (translation lookaside buffer) misses without downsides like application changes and virtual memory inflexibility.
This is disabled by default and can be enabled by setting a loader tunablevm.pmap.pg_ps_enabledto1.
In 2014 it was added to FreeBSD 10.0 for ARMv6/v7. It supports 4KB and 1MB pages dynamicly. Revision 25418 states that vm.pmap.sp_enabled is used (set in loader.conf). If you are not using loader then find it in sys/arm/arm/pmap-v6.c. There is a nice BSDcan presentation by Zbigniew Bodek: Transparent Superpages Support for FreeBSD on ARM
You check it using sysctl:
$ uname -rm
11.2-STABLE amd64
$ sysctl vm.pmap.pg_ps_enabled
vm.pmap.pg_ps_enabled: 1
Linux got huge page (superpage) support in 2011 with kernel version 2.6.38. See also Huge pages Introduction. On Linux (only!) this is handled by hugeadm as hinted in another answer.
As for OS X I think it is enabled by default but I am in no way an authorative source on this. It seems that when they test they simply try to allocate the superpages. I see no check if superpages are enabled or not.
answered Feb 13 at 10:38
Claus AndersenClaus Andersen
1,724415
This is about enabling superpages, which is not the same as finding out how big they are.
– OrangeDog
Feb 13 at 10:40
1
You are not in control of that. Read the release quote: It is transparent and handled dynamicly. Ideal page sizes are closely related to the architecture. The memory space must be contigous and you have no guarantee of that. This is handled by the system (and should be!). I would then ask another question where you clarify why it really is important to you. But at least I have a hard time thinking up those cases.
– Claus Andersen
Feb 13 at 10:47
Your own links show that mach's mmap allows you to request a specific superpage size. All I want to know is a convenient way to list the available sizes.
– OrangeDog
Feb 13 at 10:52
1
I only mentioned for arm. For amd64 it uses 4 KB, 2 MB and 1 GB as needed and if possible. If the memory map is fragmented - then you will get small pages. If not - then a larger. You only want the memory if it is non-fragmented? To me it reads as you are trying to outsmart the OS. Again - I would recommend a separate question to outline what you are trying to accomplish. To me you are going about this wrong. Hence I recommend another question. If not - sit back and wait - maybe you get a better answer to this one ;-)
– Claus Andersen
Feb 13 at 11:05
1
Good luck with that condescending attitude. I hope you are more personal IRL. I choose not to participate in this anymore.
– Claus Andersen
Feb 13 at 11:20
|
show 2 more comments
For the XNU and Mach kernels (MacOS/Darwin), if I'm reading the headers right, on x86_64 it's always 2MB, otherwise it's not supported.
To do this dynamically you have to do something like:
echo "#include <mach/vm_statistics.h>" | gcc -dM -E - | grep VM_FLAGS_SUPERPAGE_SIZE_
answered Feb 13 at 12:52
OrangeDogOrangeDog
432210
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f500223%2fget-the-superpage-size%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Alan L. Cox made some interesting Opteron benchmarks and was co-author of the original superpage paper (presented at Usenix 2002): Practical, transparent operating system support for superpages
Superpages was introduced in 2013 for FreeBSD 7.2 for amd64 and i386
[amd64, i386] The FreeBSD virtual memory subsystem now supports fully transparent use of superpages for application memory;
application memory pages are dynamically promoted to or demoted from superpages without any modification to application code.
This change offers the benefit of large page sizes such as improved virtual memory efficiency
and reduced TLB (translation lookaside buffer) misses without downsides like application changes and virtual memory inflexibility.
This is disabled by default and can be enabled by setting a loader tunablevm.pmap.pg_ps_enabledto1.
In 2014 it was added to FreeBSD 10.0 for ARMv6/v7. It supports 4KB and 1MB pages dynamicly. Revision 25418 states that vm.pmap.sp_enabled is used (set in loader.conf). If you are not using loader then find it in sys/arm/arm/pmap-v6.c. There is a nice BSDcan presentation by Zbigniew Bodek: Transparent Superpages Support for FreeBSD on ARM
You check it using sysctl:
$ uname -rm
11.2-STABLE amd64
$ sysctl vm.pmap.pg_ps_enabled
vm.pmap.pg_ps_enabled: 1
Linux got huge page (superpage) support in 2011 with kernel version 2.6.38. See also Huge pages Introduction. On Linux (only!) this is handled by hugeadm as hinted in another answer.
As for OS X I think it is enabled by default but I am in no way an authorative source on this. It seems that when they test they simply try to allocate the superpages. I see no check if superpages are enabled or not.
answered Feb 13 at 10:38
Claus AndersenClaus Andersen
1,724415
This is about enabling superpages, which is not the same as finding out how big they are.
– OrangeDog
Feb 13 at 10:40
1
You are not in control of that. Read the release quote: It is transparent and handled dynamicly. Ideal page sizes are closely related to the architecture. The memory space must be contigous and you have no guarantee of that. This is handled by the system (and should be!). I would then ask another question where you clarify why it really is important to you. But at least I have a hard time thinking up those cases.
– Claus Andersen
Feb 13 at 10:47
Your own links show that mach's mmap allows you to request a specific superpage size. All I want to know is a convenient way to list the available sizes.
– OrangeDog
Feb 13 at 10:52
1
I only mentioned for arm. For amd64 it uses 4 KB, 2 MB and 1 GB as needed and if possible. If the memory map is fragmented - then you will get small pages. If not - then a larger. You only want the memory if it is non-fragmented? To me it reads as you are trying to outsmart the OS. Again - I would recommend a separate question to outline what you are trying to accomplish. To me you are going about this wrong. Hence I recommend another question. If not - sit back and wait - maybe you get a better answer to this one ;-)
– Claus Andersen
Feb 13 at 11:05
1
Good luck with that condescending attitude. I hope you are more personal IRL. I choose not to participate in this anymore.
– Claus Andersen
Feb 13 at 11:20
|
show 2 more comments
Alan L. Cox made some interesting Opteron benchmarks and was co-author of the original superpage paper (presented at Usenix 2002): Practical, transparent operating system support for superpages
Superpages was introduced in 2013 for FreeBSD 7.2 for amd64 and i386
[amd64, i386] The FreeBSD virtual memory subsystem now supports fully transparent use of superpages for application memory;
application memory pages are dynamically promoted to or demoted from superpages without any modification to application code.
This change offers the benefit of large page sizes such as improved virtual memory efficiency
and reduced TLB (translation lookaside buffer) misses without downsides like application changes and virtual memory inflexibility.
This is disabled by default and can be enabled by setting a loader tunablevm.pmap.pg_ps_enabledto1.
In 2014 it was added to FreeBSD 10.0 for ARMv6/v7. It supports 4KB and 1MB pages dynamicly. Revision 25418 states that vm.pmap.sp_enabled is used (set in loader.conf). If you are not using loader then find it in sys/arm/arm/pmap-v6.c. There is a nice BSDcan presentation by Zbigniew Bodek: Transparent Superpages Support for FreeBSD on ARM
You check it using sysctl:
$ uname -rm
11.2-STABLE amd64
$ sysctl vm.pmap.pg_ps_enabled
vm.pmap.pg_ps_enabled: 1
Linux got huge page (superpage) support in 2011 with kernel version 2.6.38. See also Huge pages Introduction. On Linux (only!) this is handled by hugeadm as hinted in another answer.
As for OS X I think it is enabled by default but I am in no way an authorative source on this. It seems that when they test they simply try to allocate the superpages. I see no check if superpages are enabled or not.
answered Feb 13 at 10:38
Claus AndersenClaus Andersen
1,724415
This is about enabling superpages, which is not the same as finding out how big they are.
– OrangeDog
Feb 13 at 10:40
1
You are not in control of that. Read the release quote: It is transparent and handled dynamicly. Ideal page sizes are closely related to the architecture. The memory space must be contigous and you have no guarantee of that. This is handled by the system (and should be!). I would then ask another question where you clarify why it really is important to you. But at least I have a hard time thinking up those cases.
– Claus Andersen
Feb 13 at 10:47
Your own links show that mach's mmap allows you to request a specific superpage size. All I want to know is a convenient way to list the available sizes.
– OrangeDog
Feb 13 at 10:52
1
I only mentioned for arm. For amd64 it uses 4 KB, 2 MB and 1 GB as needed and if possible. If the memory map is fragmented - then you will get small pages. If not - then a larger. You only want the memory if it is non-fragmented? To me it reads as you are trying to outsmart the OS. Again - I would recommend a separate question to outline what you are trying to accomplish. To me you are going about this wrong. Hence I recommend another question. If not - sit back and wait - maybe you get a better answer to this one ;-)
– Claus Andersen
Feb 13 at 11:05
1
Good luck with that condescending attitude. I hope you are more personal IRL. I choose not to participate in this anymore.
– Claus Andersen
Feb 13 at 11:20
|
show 2 more comments
Alan L. Cox made some interesting Opteron benchmarks and was co-author of the original superpage paper (presented at Usenix 2002): Practical, transparent operating system support for superpages
Superpages was introduced in 2013 for FreeBSD 7.2 for amd64 and i386
[amd64, i386] The FreeBSD virtual memory subsystem now supports fully transparent use of superpages for application memory;
application memory pages are dynamically promoted to or demoted from superpages without any modification to application code.
This change offers the benefit of large page sizes such as improved virtual memory efficiency
and reduced TLB (translation lookaside buffer) misses without downsides like application changes and virtual memory inflexibility.
This is disabled by default and can be enabled by setting a loader tunablevm.pmap.pg_ps_enabledto1.
In 2014 it was added to FreeBSD 10.0 for ARMv6/v7. It supports 4KB and 1MB pages dynamicly. Revision 25418 states that vm.pmap.sp_enabled is used (set in loader.conf). If you are not using loader then find it in sys/arm/arm/pmap-v6.c. There is a nice BSDcan presentation by Zbigniew Bodek: Transparent Superpages Support for FreeBSD on ARM
You check it using sysctl:
$ uname -rm
11.2-STABLE amd64
$ sysctl vm.pmap.pg_ps_enabled
vm.pmap.pg_ps_enabled: 1
Linux got huge page (superpage) support in 2011 with kernel version 2.6.38. See also Huge pages Introduction. On Linux (only!) this is handled by hugeadm as hinted in another answer.
As for OS X I think it is enabled by default but I am in no way an authorative source on this. It seems that when they test they simply try to allocate the superpages. I see no check if superpages are enabled or not.
answered Feb 13 at 10:38
Claus AndersenClaus Andersen
1,724415
Alan L. Cox made some interesting Opteron benchmarks and was co-author of the original superpage paper (presented at Usenix 2002): Practical, transparent operating system support for superpages
Superpages was introduced in 2013 for FreeBSD 7.2 for amd64 and i386
[amd64, i386] The FreeBSD virtual memory subsystem now supports fully transparent use of superpages for application memory;
application memory pages are dynamically promoted to or demoted from superpages without any modification to application code.
This change offers the benefit of large page sizes such as improved virtual memory efficiency
and reduced TLB (translation lookaside buffer) misses without downsides like application changes and virtual memory inflexibility.
This is disabled by default and can be enabled by setting a loader tunablevm.pmap.pg_ps_enabledto1.
In 2014 it was added to FreeBSD 10.0 for ARMv6/v7. It supports 4KB and 1MB pages dynamicly. Revision 25418 states that vm.pmap.sp_enabled is used (set in loader.conf). If you are not using loader then find it in sys/arm/arm/pmap-v6.c. There is a nice BSDcan presentation by Zbigniew Bodek: Transparent Superpages Support for FreeBSD on ARM
You check it using sysctl:
$ uname -rm
11.2-STABLE amd64
$ sysctl vm.pmap.pg_ps_enabled
vm.pmap.pg_ps_enabled: 1
Linux got huge page (superpage) support in 2011 with kernel version 2.6.38. See also Huge pages Introduction. On Linux (only!) this is handled by hugeadm as hinted in another answer.
As for OS X I think it is enabled by default but I am in no way an authorative source on this. It seems that when they test they simply try to allocate the superpages. I see no check if superpages are enabled or not.
answered Feb 13 at 10:38
Claus AndersenClaus Andersen
1,724415
edited Feb 13 at 10:49
answered Feb 13 at 10:38
Claus AndersenClaus Andersen
1,724415
answered Feb 13 at 10:38
Claus AndersenClaus Andersen
1,724415
answered Feb 13 at 10:38
Claus AndersenClaus Andersen
1,724415
1,724415
This is about enabling superpages, which is not the same as finding out how big they are.
– OrangeDog
Feb 13 at 10:40
1
You are not in control of that. Read the release quote: It is transparent and handled dynamicly. Ideal page sizes are closely related to the architecture. The memory space must be contigous and you have no guarantee of that. This is handled by the system (and should be!). I would then ask another question where you clarify why it really is important to you. But at least I have a hard time thinking up those cases.
– Claus Andersen
Feb 13 at 10:47
Your own links show that mach's mmap allows you to request a specific superpage size. All I want to know is a convenient way to list the available sizes.
– OrangeDog
Feb 13 at 10:52
1
I only mentioned for arm. For amd64 it uses 4 KB, 2 MB and 1 GB as needed and if possible. If the memory map is fragmented - then you will get small pages. If not - then a larger. You only want the memory if it is non-fragmented? To me it reads as you are trying to outsmart the OS. Again - I would recommend a separate question to outline what you are trying to accomplish. To me you are going about this wrong. Hence I recommend another question. If not - sit back and wait - maybe you get a better answer to this one ;-)
– Claus Andersen
Feb 13 at 11:05
1
Good luck with that condescending attitude. I hope you are more personal IRL. I choose not to participate in this anymore.
– Claus Andersen
Feb 13 at 11:20
|
show 2 more comments
This is about enabling superpages, which is not the same as finding out how big they are.
– OrangeDog
Feb 13 at 10:40
1
You are not in control of that. Read the release quote: It is transparent and handled dynamicly. Ideal page sizes are closely related to the architecture. The memory space must be contigous and you have no guarantee of that. This is handled by the system (and should be!). I would then ask another question where you clarify why it really is important to you. But at least I have a hard time thinking up those cases.
– Claus Andersen
Feb 13 at 10:47
Your own links show that mach's mmap allows you to request a specific superpage size. All I want to know is a convenient way to list the available sizes.
– OrangeDog
Feb 13 at 10:52
1
I only mentioned for arm. For amd64 it uses 4 KB, 2 MB and 1 GB as needed and if possible. If the memory map is fragmented - then you will get small pages. If not - then a larger. You only want the memory if it is non-fragmented? To me it reads as you are trying to outsmart the OS. Again - I would recommend a separate question to outline what you are trying to accomplish. To me you are going about this wrong. Hence I recommend another question. If not - sit back and wait - maybe you get a better answer to this one ;-)
– Claus Andersen
Feb 13 at 11:05
1
Good luck with that condescending attitude. I hope you are more personal IRL. I choose not to participate in this anymore.
– Claus Andersen
Feb 13 at 11:20
This is about enabling superpages, which is not the same as finding out how big they are.
– OrangeDog
Feb 13 at 10:40
This is about enabling superpages, which is not the same as finding out how big they are.
– OrangeDog
Feb 13 at 10:40
1
1
You are not in control of that. Read the release quote: It is transparent and handled dynamicly. Ideal page sizes are closely related to the architecture. The memory space must be contigous and you have no guarantee of that. This is handled by the system (and should be!). I would then ask another question where you clarify why it really is important to you. But at least I have a hard time thinking up those cases.
– Claus Andersen
Feb 13 at 10:47
You are not in control of that. Read the release quote: It is transparent and handled dynamicly. Ideal page sizes are closely related to the architecture. The memory space must be contigous and you have no guarantee of that. This is handled by the system (and should be!). I would then ask another question where you clarify why it really is important to you. But at least I have a hard time thinking up those cases.
– Claus Andersen
Feb 13 at 10:47
Your own links show that mach's mmap allows you to request a specific superpage size. All I want to know is a convenient way to list the available sizes.
– OrangeDog
Feb 13 at 10:52
Your own links show that mach's mmap allows you to request a specific superpage size. All I want to know is a convenient way to list the available sizes.
– OrangeDog
Feb 13 at 10:52
1
1
I only mentioned for arm. For amd64 it uses 4 KB, 2 MB and 1 GB as needed and if possible. If the memory map is fragmented - then you will get small pages. If not - then a larger. You only want the memory if it is non-fragmented? To me it reads as you are trying to outsmart the OS. Again - I would recommend a separate question to outline what you are trying to accomplish. To me you are going about this wrong. Hence I recommend another question. If not - sit back and wait - maybe you get a better answer to this one ;-)
– Claus Andersen
Feb 13 at 11:05
I only mentioned for arm. For amd64 it uses 4 KB, 2 MB and 1 GB as needed and if possible. If the memory map is fragmented - then you will get small pages. If not - then a larger. You only want the memory if it is non-fragmented? To me it reads as you are trying to outsmart the OS. Again - I would recommend a separate question to outline what you are trying to accomplish. To me you are going about this wrong. Hence I recommend another question. If not - sit back and wait - maybe you get a better answer to this one ;-)
– Claus Andersen
Feb 13 at 11:05
1
1
Good luck with that condescending attitude. I hope you are more personal IRL. I choose not to participate in this anymore.
– Claus Andersen
Feb 13 at 11:20
Good luck with that condescending attitude. I hope you are more personal IRL. I choose not to participate in this anymore.
– Claus Andersen
Feb 13 at 11:20
|
show 2 more comments
For the XNU and Mach kernels (MacOS/Darwin), if I'm reading the headers right, on x86_64 it's always 2MB, otherwise it's not supported.
To do this dynamically you have to do something like:
echo "#include <mach/vm_statistics.h>" | gcc -dM -E - | grep VM_FLAGS_SUPERPAGE_SIZE_
answered Feb 13 at 12:52
OrangeDogOrangeDog
432210
add a comment |
For the XNU and Mach kernels (MacOS/Darwin), if I'm reading the headers right, on x86_64 it's always 2MB, otherwise it's not supported.
To do this dynamically you have to do something like:
echo "#include <mach/vm_statistics.h>" | gcc -dM -E - | grep VM_FLAGS_SUPERPAGE_SIZE_
answered Feb 13 at 12:52
OrangeDogOrangeDog
432210
add a comment |
For the XNU and Mach kernels (MacOS/Darwin), if I'm reading the headers right, on x86_64 it's always 2MB, otherwise it's not supported.
To do this dynamically you have to do something like:
echo "#include <mach/vm_statistics.h>" | gcc -dM -E - | grep VM_FLAGS_SUPERPAGE_SIZE_
answered Feb 13 at 12:52
OrangeDogOrangeDog
432210
For the XNU and Mach kernels (MacOS/Darwin), if I'm reading the headers right, on x86_64 it's always 2MB, otherwise it's not supported.
To do this dynamically you have to do something like:
echo "#include <mach/vm_statistics.h>" | gcc -dM -E - | grep VM_FLAGS_SUPERPAGE_SIZE_
answered Feb 13 at 12:52
OrangeDogOrangeDog
432210
answered Feb 13 at 12:52
OrangeDogOrangeDog
432210
answered Feb 13 at 12:52
OrangeDogOrangeDog
432210
answered Feb 13 at 12:52
OrangeDogOrangeDog
432210
432210
add a comment |
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f500223%2fget-the-superpage-size%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
