Can the Linux kernel use default virtual memory page size that is larger than 4KB without modification of the kernel?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
We are designing a CPU that would benefit from a virtual memory page size of 16KB (it will make cache access lower power and improve performance on our target workloads, memory fragmentation is not an issue). The standard page size is 4KB. Does the kernel source have a simple way to configure default page size to 16KB? Or will we need to modify the kernel source in order to change from 4KB to 16KB? What unintended side effects would happen, say with file systems, by having a 16KB virtual memory page size?
If you have any URLs that go into more depth on this for the Linux kernel, that would be great.
Thank you :-)
linux-kernel
asked Mar 25 at 1:29
seanhalle
1082
add a comment |Â
up vote
1
down vote
favorite
We are designing a CPU that would benefit from a virtual memory page size of 16KB (it will make cache access lower power and improve performance on our target workloads, memory fragmentation is not an issue). The standard page size is 4KB. Does the kernel source have a simple way to configure default page size to 16KB? Or will we need to modify the kernel source in order to change from 4KB to 16KB? What unintended side effects would happen, say with file systems, by having a 16KB virtual memory page size?
If you have any URLs that go into more depth on this for the Linux kernel, that would be great.
Thank you :-)
linux-kernel
asked Mar 25 at 1:29
seanhalle
1082
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
We are designing a CPU that would benefit from a virtual memory page size of 16KB (it will make cache access lower power and improve performance on our target workloads, memory fragmentation is not an issue). The standard page size is 4KB. Does the kernel source have a simple way to configure default page size to 16KB? Or will we need to modify the kernel source in order to change from 4KB to 16KB? What unintended side effects would happen, say with file systems, by having a 16KB virtual memory page size?
If you have any URLs that go into more depth on this for the Linux kernel, that would be great.
Thank you :-)
linux-kernel
asked Mar 25 at 1:29
seanhalle
1082
We are designing a CPU that would benefit from a virtual memory page size of 16KB (it will make cache access lower power and improve performance on our target workloads, memory fragmentation is not an issue). The standard page size is 4KB. Does the kernel source have a simple way to configure default page size to 16KB? Or will we need to modify the kernel source in order to change from 4KB to 16KB? What unintended side effects would happen, say with file systems, by having a 16KB virtual memory page size?
If you have any URLs that go into more depth on this for the Linux kernel, that would be great.
Thank you :-)
linux-kernel
asked Mar 25 at 1:29
seanhalle
1082
asked Mar 25 at 1:29
seanhalle
1082
asked Mar 25 at 1:29
seanhalle
1082
asked Mar 25 at 1:29
seanhalle
1082
1082
add a comment |Â
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
Yes, the Linux kernel has support for page sizes other than 4KB and in some cases defaults to those page sizes.
On the x86_64 architecture, only 4KB is supported (AFAIK) since that's the only thing those chips can do...
As an example, the ppc64 architecture defaults to 64KB pages, though there is a kernel compile-time configuration to use 4KB pages (although it's less tested than the 64KB one, so maybe not recommended for that reason.)
For aarch64 platform (ARM) I believe the kernel has support for 4KB, 16KB and 64KB page sizes, from having seen these page sizes on ARM with Linux running on them. (I believe these are all coming from upstream kernel.)
You say "we are designing a CPU" and talk about kernel source modifications... Well, if it's a new architecture, then you'll need to add support for it in the kernel and that includes page size support! If it's an implementation of an existing architecture (such as aarch64) then you might be able to use the existing support, though it's likely you might need to add something about your specific CPU to the kernel for it to support it...
Regarding filesystems, the block size of filesystem does not need to match the page size. It's possible to use ext4 formatted with the default 4KB block size on machines with 16KB or 64KB page size.
The one are where these two tend to get interrelated is the use of O_DIRECT to bypass the page cache when reading/writing to the filesystem. But that still works, newer kernels in general only require alignment at the 512-byte boundary.
In other words, there are no requirements to have page size and filesystem block size to match in any way.
answered Mar 25 at 3:43
Filipe Brandenburger
3,461621
1
x86 also has huge pages (2 MiB and 1 GiB) alongside its 4 KiB pages.
– Stephen Kitt
Mar 25 at 3:59
Thanks. Huge help. This is for RISC-V, so the kernel is already upstreamed, with both Debian and Fedora ports. We want to avoid modifications of the kernel and any complications for porting code to our platform. It sounds like changing VM page size to 16KB is relatively painless, and sounds as though it may be fairly safe to do, as far as unintended consequences.. still worry about things like hypervisors and device drivers.. seems too easy :-)
– seanhalle
Mar 28 at 7:38
@seanhalle It looks like right now kernel support for RISC-V only supports 4KB pages though... See arch/riscv/include/asm/page.h in the kernel source. So you might actually have some work to make that support different page sizes... The kernel as a whole supports it, so it's just the matter of adding support to your particular architecture.
– Filipe Brandenburger
Mar 29 at 2:41
You might want to contact one of the RISC-V mailing lists, for instance the hw-dev@ one might be a good place to ask these questions...
– Filipe Brandenburger
Mar 29 at 2:48
Thanks Filipe. From my reading, it looks like PAGE_SHIFT sets the number of bits, and everything else derives from there.. the real question is, what down stream effects does this cause? Is just setting that to 14 bits enough? Or will we need to dig into deeper parts of the kernel, finding places that get broken by this change?
– seanhalle
Mar 29 at 22:19
 |Â
show 1 more comment
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
Yes, the Linux kernel has support for page sizes other than 4KB and in some cases defaults to those page sizes.
On the x86_64 architecture, only 4KB is supported (AFAIK) since that's the only thing those chips can do...
As an example, the ppc64 architecture defaults to 64KB pages, though there is a kernel compile-time configuration to use 4KB pages (although it's less tested than the 64KB one, so maybe not recommended for that reason.)
For aarch64 platform (ARM) I believe the kernel has support for 4KB, 16KB and 64KB page sizes, from having seen these page sizes on ARM with Linux running on them. (I believe these are all coming from upstream kernel.)
You say "we are designing a CPU" and talk about kernel source modifications... Well, if it's a new architecture, then you'll need to add support for it in the kernel and that includes page size support! If it's an implementation of an existing architecture (such as aarch64) then you might be able to use the existing support, though it's likely you might need to add something about your specific CPU to the kernel for it to support it...
Regarding filesystems, the block size of filesystem does not need to match the page size. It's possible to use ext4 formatted with the default 4KB block size on machines with 16KB or 64KB page size.
The one are where these two tend to get interrelated is the use of O_DIRECT to bypass the page cache when reading/writing to the filesystem. But that still works, newer kernels in general only require alignment at the 512-byte boundary.
In other words, there are no requirements to have page size and filesystem block size to match in any way.
answered Mar 25 at 3:43
Filipe Brandenburger
3,461621
1
x86 also has huge pages (2 MiB and 1 GiB) alongside its 4 KiB pages.
– Stephen Kitt
Mar 25 at 3:59
Thanks. Huge help. This is for RISC-V, so the kernel is already upstreamed, with both Debian and Fedora ports. We want to avoid modifications of the kernel and any complications for porting code to our platform. It sounds like changing VM page size to 16KB is relatively painless, and sounds as though it may be fairly safe to do, as far as unintended consequences.. still worry about things like hypervisors and device drivers.. seems too easy :-)
– seanhalle
Mar 28 at 7:38
@seanhalle It looks like right now kernel support for RISC-V only supports 4KB pages though... See arch/riscv/include/asm/page.h in the kernel source. So you might actually have some work to make that support different page sizes... The kernel as a whole supports it, so it's just the matter of adding support to your particular architecture.
– Filipe Brandenburger
Mar 29 at 2:41
You might want to contact one of the RISC-V mailing lists, for instance the hw-dev@ one might be a good place to ask these questions...
– Filipe Brandenburger
Mar 29 at 2:48
Thanks Filipe. From my reading, it looks like PAGE_SHIFT sets the number of bits, and everything else derives from there.. the real question is, what down stream effects does this cause? Is just setting that to 14 bits enough? Or will we need to dig into deeper parts of the kernel, finding places that get broken by this change?
– seanhalle
Mar 29 at 22:19
 |Â
show 1 more comment
up vote
1
down vote
accepted
Yes, the Linux kernel has support for page sizes other than 4KB and in some cases defaults to those page sizes.
On the x86_64 architecture, only 4KB is supported (AFAIK) since that's the only thing those chips can do...
As an example, the ppc64 architecture defaults to 64KB pages, though there is a kernel compile-time configuration to use 4KB pages (although it's less tested than the 64KB one, so maybe not recommended for that reason.)
For aarch64 platform (ARM) I believe the kernel has support for 4KB, 16KB and 64KB page sizes, from having seen these page sizes on ARM with Linux running on them. (I believe these are all coming from upstream kernel.)
You say "we are designing a CPU" and talk about kernel source modifications... Well, if it's a new architecture, then you'll need to add support for it in the kernel and that includes page size support! If it's an implementation of an existing architecture (such as aarch64) then you might be able to use the existing support, though it's likely you might need to add something about your specific CPU to the kernel for it to support it...
Regarding filesystems, the block size of filesystem does not need to match the page size. It's possible to use ext4 formatted with the default 4KB block size on machines with 16KB or 64KB page size.
The one are where these two tend to get interrelated is the use of O_DIRECT to bypass the page cache when reading/writing to the filesystem. But that still works, newer kernels in general only require alignment at the 512-byte boundary.
In other words, there are no requirements to have page size and filesystem block size to match in any way.
answered Mar 25 at 3:43
Filipe Brandenburger
3,461621
1
x86 also has huge pages (2 MiB and 1 GiB) alongside its 4 KiB pages.
– Stephen Kitt
Mar 25 at 3:59
Thanks. Huge help. This is for RISC-V, so the kernel is already upstreamed, with both Debian and Fedora ports. We want to avoid modifications of the kernel and any complications for porting code to our platform. It sounds like changing VM page size to 16KB is relatively painless, and sounds as though it may be fairly safe to do, as far as unintended consequences.. still worry about things like hypervisors and device drivers.. seems too easy :-)
– seanhalle
Mar 28 at 7:38
@seanhalle It looks like right now kernel support for RISC-V only supports 4KB pages though... See arch/riscv/include/asm/page.h in the kernel source. So you might actually have some work to make that support different page sizes... The kernel as a whole supports it, so it's just the matter of adding support to your particular architecture.
– Filipe Brandenburger
Mar 29 at 2:41
You might want to contact one of the RISC-V mailing lists, for instance the hw-dev@ one might be a good place to ask these questions...
– Filipe Brandenburger
Mar 29 at 2:48
Thanks Filipe. From my reading, it looks like PAGE_SHIFT sets the number of bits, and everything else derives from there.. the real question is, what down stream effects does this cause? Is just setting that to 14 bits enough? Or will we need to dig into deeper parts of the kernel, finding places that get broken by this change?
– seanhalle
Mar 29 at 22:19
 |Â
show 1 more comment
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Yes, the Linux kernel has support for page sizes other than 4KB and in some cases defaults to those page sizes.
On the x86_64 architecture, only 4KB is supported (AFAIK) since that's the only thing those chips can do...
As an example, the ppc64 architecture defaults to 64KB pages, though there is a kernel compile-time configuration to use 4KB pages (although it's less tested than the 64KB one, so maybe not recommended for that reason.)
For aarch64 platform (ARM) I believe the kernel has support for 4KB, 16KB and 64KB page sizes, from having seen these page sizes on ARM with Linux running on them. (I believe these are all coming from upstream kernel.)
You say "we are designing a CPU" and talk about kernel source modifications... Well, if it's a new architecture, then you'll need to add support for it in the kernel and that includes page size support! If it's an implementation of an existing architecture (such as aarch64) then you might be able to use the existing support, though it's likely you might need to add something about your specific CPU to the kernel for it to support it...
Regarding filesystems, the block size of filesystem does not need to match the page size. It's possible to use ext4 formatted with the default 4KB block size on machines with 16KB or 64KB page size.
The one are where these two tend to get interrelated is the use of O_DIRECT to bypass the page cache when reading/writing to the filesystem. But that still works, newer kernels in general only require alignment at the 512-byte boundary.
In other words, there are no requirements to have page size and filesystem block size to match in any way.
answered Mar 25 at 3:43
Filipe Brandenburger
3,461621
Yes, the Linux kernel has support for page sizes other than 4KB and in some cases defaults to those page sizes.
On the x86_64 architecture, only 4KB is supported (AFAIK) since that's the only thing those chips can do...
As an example, the ppc64 architecture defaults to 64KB pages, though there is a kernel compile-time configuration to use 4KB pages (although it's less tested than the 64KB one, so maybe not recommended for that reason.)
For aarch64 platform (ARM) I believe the kernel has support for 4KB, 16KB and 64KB page sizes, from having seen these page sizes on ARM with Linux running on them. (I believe these are all coming from upstream kernel.)
You say "we are designing a CPU" and talk about kernel source modifications... Well, if it's a new architecture, then you'll need to add support for it in the kernel and that includes page size support! If it's an implementation of an existing architecture (such as aarch64) then you might be able to use the existing support, though it's likely you might need to add something about your specific CPU to the kernel for it to support it...
Regarding filesystems, the block size of filesystem does not need to match the page size. It's possible to use ext4 formatted with the default 4KB block size on machines with 16KB or 64KB page size.
The one are where these two tend to get interrelated is the use of O_DIRECT to bypass the page cache when reading/writing to the filesystem. But that still works, newer kernels in general only require alignment at the 512-byte boundary.
In other words, there are no requirements to have page size and filesystem block size to match in any way.
answered Mar 25 at 3:43
Filipe Brandenburger
3,461621
answered Mar 25 at 3:43
Filipe Brandenburger
3,461621
answered Mar 25 at 3:43
Filipe Brandenburger
3,461621
answered Mar 25 at 3:43
Filipe Brandenburger
3,461621
3,461621
1
x86 also has huge pages (2 MiB and 1 GiB) alongside its 4 KiB pages.
– Stephen Kitt
Mar 25 at 3:59
Thanks. Huge help. This is for RISC-V, so the kernel is already upstreamed, with both Debian and Fedora ports. We want to avoid modifications of the kernel and any complications for porting code to our platform. It sounds like changing VM page size to 16KB is relatively painless, and sounds as though it may be fairly safe to do, as far as unintended consequences.. still worry about things like hypervisors and device drivers.. seems too easy :-)
– seanhalle
Mar 28 at 7:38
@seanhalle It looks like right now kernel support for RISC-V only supports 4KB pages though... See arch/riscv/include/asm/page.h in the kernel source. So you might actually have some work to make that support different page sizes... The kernel as a whole supports it, so it's just the matter of adding support to your particular architecture.
– Filipe Brandenburger
Mar 29 at 2:41
You might want to contact one of the RISC-V mailing lists, for instance the hw-dev@ one might be a good place to ask these questions...
– Filipe Brandenburger
Mar 29 at 2:48
Thanks Filipe. From my reading, it looks like PAGE_SHIFT sets the number of bits, and everything else derives from there.. the real question is, what down stream effects does this cause? Is just setting that to 14 bits enough? Or will we need to dig into deeper parts of the kernel, finding places that get broken by this change?
– seanhalle
Mar 29 at 22:19
 |Â
show 1 more comment
1
x86 also has huge pages (2 MiB and 1 GiB) alongside its 4 KiB pages.
– Stephen Kitt
Mar 25 at 3:59
Thanks. Huge help. This is for RISC-V, so the kernel is already upstreamed, with both Debian and Fedora ports. We want to avoid modifications of the kernel and any complications for porting code to our platform. It sounds like changing VM page size to 16KB is relatively painless, and sounds as though it may be fairly safe to do, as far as unintended consequences.. still worry about things like hypervisors and device drivers.. seems too easy :-)
– seanhalle
Mar 28 at 7:38
@seanhalle It looks like right now kernel support for RISC-V only supports 4KB pages though... See arch/riscv/include/asm/page.h in the kernel source. So you might actually have some work to make that support different page sizes... The kernel as a whole supports it, so it's just the matter of adding support to your particular architecture.
– Filipe Brandenburger
Mar 29 at 2:41
You might want to contact one of the RISC-V mailing lists, for instance the hw-dev@ one might be a good place to ask these questions...
– Filipe Brandenburger
Mar 29 at 2:48
Thanks Filipe. From my reading, it looks like PAGE_SHIFT sets the number of bits, and everything else derives from there.. the real question is, what down stream effects does this cause? Is just setting that to 14 bits enough? Or will we need to dig into deeper parts of the kernel, finding places that get broken by this change?
– seanhalle
Mar 29 at 22:19
1
1
x86 also has huge pages (2 MiB and 1 GiB) alongside its 4 KiB pages.
– Stephen Kitt
Mar 25 at 3:59
x86 also has huge pages (2 MiB and 1 GiB) alongside its 4 KiB pages.
– Stephen Kitt
Mar 25 at 3:59
Thanks. Huge help. This is for RISC-V, so the kernel is already upstreamed, with both Debian and Fedora ports. We want to avoid modifications of the kernel and any complications for porting code to our platform. It sounds like changing VM page size to 16KB is relatively painless, and sounds as though it may be fairly safe to do, as far as unintended consequences.. still worry about things like hypervisors and device drivers.. seems too easy :-)
– seanhalle
Mar 28 at 7:38
Thanks. Huge help. This is for RISC-V, so the kernel is already upstreamed, with both Debian and Fedora ports. We want to avoid modifications of the kernel and any complications for porting code to our platform. It sounds like changing VM page size to 16KB is relatively painless, and sounds as though it may be fairly safe to do, as far as unintended consequences.. still worry about things like hypervisors and device drivers.. seems too easy :-)
– seanhalle
Mar 28 at 7:38
@seanhalle It looks like right now kernel support for RISC-V only supports 4KB pages though... See arch/riscv/include/asm/page.h in the kernel source. So you might actually have some work to make that support different page sizes... The kernel as a whole supports it, so it's just the matter of adding support to your particular architecture.
– Filipe Brandenburger
Mar 29 at 2:41
@seanhalle It looks like right now kernel support for RISC-V only supports 4KB pages though... See arch/riscv/include/asm/page.h in the kernel source. So you might actually have some work to make that support different page sizes... The kernel as a whole supports it, so it's just the matter of adding support to your particular architecture.
– Filipe Brandenburger
Mar 29 at 2:41
You might want to contact one of the RISC-V mailing lists, for instance the hw-dev@ one might be a good place to ask these questions...
– Filipe Brandenburger
Mar 29 at 2:48
You might want to contact one of the RISC-V mailing lists, for instance the hw-dev@ one might be a good place to ask these questions...
– Filipe Brandenburger
Mar 29 at 2:48
Thanks Filipe. From my reading, it looks like PAGE_SHIFT sets the number of bits, and everything else derives from there.. the real question is, what down stream effects does this cause? Is just setting that to 14 bits enough? Or will we need to dig into deeper parts of the kernel, finding places that get broken by this change?
– seanhalle
Mar 29 at 22:19
Thanks Filipe. From my reading, it looks like PAGE_SHIFT sets the number of bits, and everything else derives from there.. the real question is, what down stream effects does this cause? Is just setting that to 14 bits enough? Or will we need to dig into deeper parts of the kernel, finding places that get broken by this change?
– seanhalle
Mar 29 at 22:19
 |Â
show 1 more comment
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
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f433352%2fcan-the-linux-kernel-use-default-virtual-memory-page-size-that-is-larger-than-4k%23new-answer', 'question_page');
);
Post as a guest
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
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
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
