shrinking struct page (part of page pool)
Subsystems (3)
Hi guys,
I'm looking at network's page pool code to help 'shrinking struct page' project by Matthew Wilcox. See the following link:
https://kernelnewbies.org/MatthewWilcox/Memdescs/Path
My first goal is to remove fields for page pool from struct page like:
struct { /* page_pool used by netstack */
/** * @pp_magic: magic value to avoid recycling non * page_pool allocated pages. */ unsigned long pp_magic; struct page_pool *pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t pp_ref_count;
};
Fortunately, many prerequisite works have been done by Mina but I guess he or she has done it for other purpose than 'shrinking struct page'.
I'd like to just finalize the work so that the fields above can be removed from struct page. However, I need to resolve a curiousity before starting.
Network guys already introduced a sperate strcut, struct net_iov, to overlay the interesting fields. However, another separate struct for system memory might be also needed e.g. struct bump so that struct net_iov and struct bump can be overlayed depending on the source:
struct bump {
unsigned long _page_flags;
unsigned long bump_magic;
struct page_pool *bump_pp;
unsigned long _pp_mapping_pad;
unsigned long dma_addr;
atomic_long_t bump_ref_count;
unsigned int _page_type;
atomic_t _refcount;};
To netwrok guys, any thoughts on it?
To Willy, do I understand correctly your direction?
Plus, it's a quite another issue but I'm curious, that is, what do you guys think about moving the bump allocator(= page pool) code from network to mm? I'd like to start on the work once gathering opinion from both Willy and network guys.
Byungchul
Quoted 1 line · Byungchul Park
Hi guys,
+cc [email protected]
+cc [email protected]
Byungchul
Quoted 52 lines
I'm looking at network's page pool code to help 'shrinking struct page' project by Matthew Wilcox. See the following link:
https://kernelnewbies.org/MatthewWilcox/Memdescs/Path
My first goal is to remove fields for page pool from struct page like:
struct { /* page_pool used by netstack */ /** * @pp_magic: magic value to avoid recycling non * page_pool allocated pages. */ unsigned long pp_magic; struct page_pool *pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t pp_ref_count; };Fortunately, many prerequisite works have been done by Mina but I guess he or she has done it for other purpose than 'shrinking struct page'.
I'd like to just finalize the work so that the fields above can be removed from struct page. However, I need to resolve a curiousity before starting.
Network guys already introduced a sperate strcut, struct net_iov, to overlay the interesting fields. However, another separate struct for system memory might be also needed e.g. struct bump so that struct net_iov and struct bump can be overlayed depending on the source: struct bump { unsigned long _page_flags; unsigned long bump_magic; struct page_pool *bump_pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t bump_ref_count; unsigned int _page_type; atomic_t _refcount; };To netwrok guys, any thoughts on it?
To Willy, do I understand correctly your direction?Plus, it's a quite another issue but I'm curious, that is, what do you guys think about moving the bump allocator(= page pool) code from network to mm? I'd like to start on the work once gathering opinion from both Willy and network guys.
Byungchul
Jakub Kicinski
maintainerQuoted 6 lines · On Mon, 14 Apr 2025 10:52:07 +0900 Byungchul Park wrote:
Quoted 6 lines
Fortunately, many prerequisite works have been done by Mina but I guess he or she has done it for other purpose than 'shrinking struct page'.
I'd like to just finalize the work so that the fields above can be removed from struct page. However, I need to resolve a curiousity before starting.
I don't understand what the question is but FWIW from my perspective the ZC APIs are fairly contained, or at least we tried to make sure that net_iov pages cannot reach random parts of the stack.
Replacing all uses of struct page would require converting much more of the stack, AFAIU. But that's best discussed over posted patches.
Quoted 17 lines
Quoted 17 lines
Network guys already introduced a sperate strcut, struct net_iov, to overlay the interesting fields. However, another separate struct for system memory might be also needed e.g. struct bump so that struct net_iov and struct bump can be overlayed depending on the source: struct bump { unsigned long _page_flags; unsigned long bump_magic; struct page_pool *bump_pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t bump_ref_count; unsigned int _page_type; atomic_t _refcount; };
Quoted 7 lines
Quoted 7 lines
To netwrok guys, any thoughts on it?
To Willy, do I understand correctly your direction?Plus, it's a quite another issue but I'm curious, that is, what do you guys think about moving the bump allocator(= page pool) code from network to mm? I'd like to start on the work once gathering opinion from both Willy and network guys.
I don't see any benefit from moving page pool to MM. It is quite networking specific. But we can discuss this later. Moving code is trivial, it should not be the initial focus.
Quoted 10 lines · Byungchul Park
Hi guys,
I'm looking at network's page pool code to help 'shrinking struct page' project by Matthew Wilcox. See the following link:
https://kernelnewbies.org/MatthewWilcox/Memdescs/Path
My first goal is to remove fields for page pool from struct page like:
Remove them, but put them where? The page above specificies "Split the pagepool bump allocator out of struct page, as has been done for, eg, slab and ptdesc.", but I'm not familiar what happened with slab and ptdesc. Are these fields moving to a different location? Or being somehow removed entirely?
Quoted 12 lines
struct { /* page_pool used by netstack */
/**
* @pp_magic: magic value to avoid recycling non
* page_pool allocated pages.
*/
unsigned long pp_magic;
struct page_pool *pp;
unsigned long _pp_mapping_pad;
unsigned long dma_addr;
atomic_long_t pp_ref_count;
};Quoted 3 lines
Fortunately, many prerequisite works have been done by Mina but I guess he or she has done it for other purpose than 'shrinking struct page'.
Yeah, we did it to support non-page memory in the net stack, which is quite orthogonal to what you're trying to do AFAICT so far. Looks like maybe some implementation details are shared by luck?
Quoted 21 lines
I'd like to just finalize the work so that the fields above can be removed from struct page. However, I need to resolve a curiousity before starting.
Network guys already introduced a sperate strcut, struct net_iov, to overlay the interesting fields. However, another separate struct for system memory might be also needed e.g. struct bump so that struct net_iov and struct bump can be overlayed depending on the source: struct bump { unsigned long _page_flags; unsigned long bump_magic; struct page_pool *bump_pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t bump_ref_count; unsigned int _page_type; atomic_t _refcount; };
Quoted 1 line
To netwrok guys, any thoughts on it?
Need more details. What does struct bump represent? If it's meant to replace the fields used by the page_pool referenced above, then it should not have _page_flags, bump_ref_count should be pp_ref_count, and should not have _page_type or _refcount.
Quoted 7 lines
To Willy, do I understand correctly your direction?
Plus, it's a quite another issue but I'm curious, that is, what do you guys think about moving the bump allocator(= page pool) code from network to mm? I'd like to start on the work once gathering opinion from both Willy and network guys.
What is the terminology "bump"? Are you wanting to rename page_pool to "bump"? What does the new name mean?
Signature · 2 lines
Thanks, Mina
Quoted 6 lines · Byungchul Park
Hi guys,
I'm looking at network's page pool code to help 'shrinking struct page' project by Matthew Wilcox. See the following link:
Thanks for looking at this!
Quoted 14 lines
My first goal is to remove fields for page pool from struct page like:
struct { /* page_pool used by netstack */ /** * @pp_magic: magic value to avoid recycling non * page_pool allocated pages. */ unsigned long pp_magic; struct page_pool *pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t pp_ref_count; };
Quoted 6 lines
Fortunately, many prerequisite works have been done by Mina but I guess he or she has done it for other purpose than 'shrinking struct page'.
I'd like to just finalize the work so that the fields above can be removed from struct page. However, I need to resolve a curiousity before starting.
I have a blog that walks you through what I focused on when making ptdescs. It would benefit you to look at:
https://blogs.oracle.com/linux/post/introducing-memdesc
I'll need to start looking into the networking code before I can offer any opinions about the specifics of the descriptor though.
Quoted 27 lines
Network guys already introduced a sperate strcut, struct net_iov, to overlay the interesting fields. However, another separate struct for system memory might be also needed e.g. struct bump so that struct net_iov and struct bump can be overlayed depending on the source: struct bump { unsigned long _page_flags; unsigned long bump_magic; struct page_pool *bump_pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t bump_ref_count; unsigned int _page_type; atomic_t _refcount; };To netwrok guys, any thoughts on it?
To Willy, do I understand correctly your direction?Plus, it's a quite another issue but I'm curious, that is, what do you guys think about moving the bump allocator(= page pool) code from network to mm? I'd like to start on the work once gathering opinion from both Willy and network guys.
Byungchul
Quoted 7 lines · Mina Almasry
Quoted 6 lines · Byungchul Park
Hi guys,
I'm looking at network's page pool code to help 'shrinking struct page' project by Matthew Wilcox. See the following link:
Quoted 6 lines
Quoted 4 lines
https://kernelnewbies.org/MatthewWilcox/Memdescs/Path
My first goal is to remove fields for page pool from struct page like:
Remove them, but put them where? The page above specificies "Split the
We need to introduce a new struct that will be used as a new descriptor e.g. bump, instead of struct page, similar to net_iov, overlaying struct page for now.
Quoted 3 lines
pagepool bump allocator out of struct page, as has been done for, eg, slab and ptdesc.", but I'm not familiar what happened with slab and ptdesc. Are these fields moving to a different location? Or being
Move to the newly introduced struct e.g. bump and temporarily let it overlay struct page for now.
Quoted 1 line
somehow removed entirely?
And then we can remove the fields from struct page.
Quoted 12 lines
Quoted 12 lines
struct { /* page_pool used by netstack */ /** * @pp_magic: magic value to avoid recycling non * page_pool allocated pages. */ unsigned long pp_magic; struct page_pool *pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t pp_ref_count; };
Quoted 7 lines
Quoted 3 lines
Fortunately, many prerequisite works have been done by Mina but I guess he or she has done it for other purpose than 'shrinking struct page'.
Yeah, we did it to support non-page memory in the net stack, which is quite orthogonal to what you're trying to do AFAICT so far. Looks like maybe some implementation details are shared by luck?
Oh.
Quoted 21 lines
Quoted 21 lines
I'd like to just finalize the work so that the fields above can be removed from struct page. However, I need to resolve a curiousity before starting.
Network guys already introduced a sperate strcut, struct net_iov, to overlay the interesting fields. However, another separate struct for system memory might be also needed e.g. struct bump so that struct net_iov and struct bump can be overlayed depending on the source: struct bump { unsigned long _page_flags; unsigned long bump_magic; struct page_pool *bump_pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t bump_ref_count; unsigned int _page_type; atomic_t _refcount; };
Quoted 3 lines
Quoted 1 line
To netwrok guys, any thoughts on it?
Need more details. What does struct bump represent? If it's meant to
'bump' comes from how page pool works. See the following link:
https://en.wikipedia.org/wiki/Region-based_memory_management
However, any better name suggestion from network guys should be appreciated.
Quoted 3 lines
replace the fields used by the
page_poolreferenced above, then it should not have_page_flags,bump_ref_countshould bepp_ref_count, and should not have_page_typeor_refcount.
These are place holders that might be needed for now but should be removed later.
Quoted 10 lines
Quoted 7 lines
To Willy, do I understand correctly your direction?
Plus, it's a quite another issue but I'm curious, that is, what do you guys think about moving the bump allocator(= page pool) code from network to mm? I'd like to start on the work once gathering opinion from both Willy and network guys.
What is the terminology "bump"? Are you wanting to rename
page_poolto "bump"? What does the new name mean?
I hope the link above explain it.
Byungchul
Quoted 4 lines
Signature · 3 lines
-- Thanks, Mina
Quoted 27 lines · Vishal Moola (Oracle)
Quoted 6 lines · Byungchul Park
Hi guys,
I'm looking at network's page pool code to help 'shrinking struct page' project by Matthew Wilcox. See the following link:
Thanks for looking at this!
Quoted 17 lines
My first goal is to remove fields for page pool from struct page like:
struct { /* page_pool used by netstack */ /** * @pp_magic: magic value to avoid recycling non * page_pool allocated pages. */ unsigned long pp_magic; struct page_pool *pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t pp_ref_count; };Fortunately, many prerequisite works have been done by Mina but I guess he or she has done it for other purpose than 'shrinking struct page'.
Quoted 8 lines
Quoted 3 lines
I'd like to just finalize the work so that the fields above can be removed from struct page. However, I need to resolve a curiousity before starting.
I have a blog that walks you through what I focused on when making ptdescs. It would benefit you to look at:
Hi bro,
Thank you for sharing the blog.
Byungchul
Quoted 30 lines
I'll need to start looking into the networking code before I can offer any opinions about the specifics of the descriptor though.
Quoted 27 lines
Network guys already introduced a sperate strcut, struct net_iov, to overlay the interesting fields. However, another separate struct for system memory might be also needed e.g. struct bump so that struct net_iov and struct bump can be overlayed depending on the source: struct bump { unsigned long _page_flags; unsigned long bump_magic; struct page_pool *bump_pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t bump_ref_count; unsigned int _page_type; atomic_t _refcount; };To netwrok guys, any thoughts on it?
To Willy, do I understand correctly your direction?Plus, it's a quite another issue but I'm curious, that is, what do you guys think about moving the bump allocator(= page pool) code from network to mm? I'd like to start on the work once gathering opinion from both Willy and network guys.
Byungchul
Quoted 8 lines · Jakub Kicinski
Quoted 6 lines · On Mon, 14 Apr 2025 10:52:07 +0900 Byungchul Park wrote:
Quoted 6 lines
Fortunately, many prerequisite works have been done by Mina but I guess he or she has done it for other purpose than 'shrinking struct page'.
I'd like to just finalize the work so that the fields above can be removed from struct page. However, I need to resolve a curiousity before starting.
Quoted 6 lines
I don't understand what the question is but FWIW from my perspective the ZC APIs are fairly contained, or at least we tried to make sure that
net_iovpages cannot reach random parts of the stack.Replacing all uses of struct page would require converting much more of the stack, AFAIU. But that's best discussed over posted patches.
Okay. Let's discuss it once posting patches.
Quoted 20 lines
Quoted 20 lines
Quoted 20 lines
Network guys already introduced a sperate strcut, struct net_iov, to overlay the interesting fields. However, another separate struct for system memory might be also needed e.g. struct bump so that struct net_iov and struct bump can be overlayed depending on the source: struct bump { unsigned long _page_flags; unsigned long bump_magic; struct page_pool *bump_pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t bump_ref_count; unsigned int _page_type; atomic_t _refcount; };To netwrok guys, any thoughts on it?
To Willy, do I understand correctly your direction?
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
Plus, it's a quite another issue but I'm curious, that is, what do you guys think about moving the bump allocator(= page pool) code from network to mm? I'd like to start on the work once gathering opinion from both Willy and network guys.
I don't see any benefit from moving page pool to MM. It is quite networking specific. But we can discuss this later. Moving code is trivial, it should not be the initial focus.
I think so.
Byungchul
Quoted 24 lines · Byungchul Park
Quoted 7 lines · Mina Almasry
Quoted 6 lines · Byungchul Park
Hi guys,
I'm looking at network's page pool code to help 'shrinking struct page' project by Matthew Wilcox. See the following link:
Quoted 6 lines
Quoted 4 lines
https://kernelnewbies.org/MatthewWilcox/Memdescs/Path
My first goal is to remove fields for page pool from struct page like:
Remove them, but put them where? The page above specificies "Split the
We need to introduce a new struct that will be used as a new descriptor e.g. bump, instead of struct page, similar to
net_iov, overlaying struct page for now.Quoted 3 lines
pagepool bump allocator out of struct page, as has been done for, eg, slab and ptdesc.", but I'm not familiar what happened with slab and ptdesc. Are these fields moving to a different location? Or being
Quoted 7 lines
Move to the newly introduced struct e.g. bump and temporarily let it overlay struct page for now.
Quoted 1 line
somehow removed entirely?
And then we can remove the fields from struct page.
OK, IIUC, what you're trying to do is fairly straightforward actually.
We already have struct net_iov which overlays the page_pool entries in struct page, and we use it to represent non-paged memory.
You can create struct bump which overlays the page_pool entries in struct page (just like net_iov does), and modify all the places in the net stack and page_pool where we query these entries to query the entries from the struct bump instead of from the struct page.
Quoted 54 lines
Quoted 12 lines
Quoted 12 lines
struct { /* page_pool used by netstack */ /** * @pp_magic: magic value to avoid recycling non * page_pool allocated pages. */ unsigned long pp_magic; struct page_pool *pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t pp_ref_count; };Quoted 7 lines
Quoted 3 lines
Fortunately, many prerequisite works have been done by Mina but I guess he or she has done it for other purpose than 'shrinking struct page'.
Yeah, we did it to support non-page memory in the net stack, which is quite orthogonal to what you're trying to do AFAICT so far. Looks like maybe some implementation details are shared by luck?
Oh.
Quoted 21 lines
Quoted 21 lines
I'd like to just finalize the work so that the fields above can be removed from struct page. However, I need to resolve a curiousity before starting.
Network guys already introduced a sperate strcut, struct net_iov, to overlay the interesting fields. However, another separate struct for system memory might be also needed e.g. struct bump so that struct net_iov and struct bump can be overlayed depending on the source: struct bump { unsigned long _page_flags; unsigned long bump_magic; struct page_pool *bump_pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t bump_ref_count; unsigned int _page_type; atomic_t _refcount; };Quoted 3 lines
Quoted 1 line
To netwrok guys, any thoughts on it?
Need more details. What does struct bump represent? If it's meant to
'bump' comes from how page pool works. See the following link:
https://en.wikipedia.org/wiki/Region-based_memory_management
However, any better name suggestion from network guys should be appreciated.
Quoted 7 lines
Quoted 3 lines
replace the fields used by the
page_poolreferenced above, then it should not have_page_flags,bump_ref_countshould bepp_ref_count, and should not have_page_typeor_refcount.These are place holders that might be needed for now but should be removed later.
I think they need to not be added at all, rather than removed later. It makes little sense to me to have a _page_type or _refcount entries in this bump struct when the original page_pool entries in struct page don't have a _page_flags or _page_type or _refcount, but maybe I misunderstood and looking at patches would make this clearer.
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
To Willy, do I understand correctly your direction?
Plus, it's a quite another issue but I'm curious, that is, what do you guys think about moving the bump allocator(= page pool) code from network to mm? I'd like to start on the work once gathering opinion from both Willy and network guys.
Quoted 5 lines
Quoted 2 lines
What is the terminology "bump"? Are you wanting to rename
page_poolto "bump"? What does the new name mean?I hope the link above explain it.
To be honest I would drop renaming the page_pool and moving the page_pool to mm as part of your changes. Those seem to have very little benefit for what you're trying to do, and what you're doing seems straightforward enough while keeping the code in place, but that's just my 2 cents.
Signature · 2 lines
Thanks, Mina
Hi Jakub
[...]
Quoted 15 lines
Quoted 15 lines
Quoted 15 lines
struct bump { unsigned long _page_flags; unsigned long bump_magic; struct page_pool *bump_pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t bump_ref_count; unsigned int _page_type; atomic_t _refcount; };To netwrok guys, any thoughts on it?
To Willy, do I understand correctly your direction?
Quoted 8 lines
Quoted 4 lines
Quoted 4 lines
Plus, it's a quite another issue but I'm curious, that is, what do you guys think about moving the bump allocator(= page pool) code from network to mm? I'd like to start on the work once gathering opinion from both Willy and network guys.
I don't see any benefit from moving page pool to MM. It is quite networking specific. But we can discuss this later. Moving code is trivial, it should not be the initial focus.
Random thoughts here until I look at the patches.
The concept of devices doing DMA + recycling the used buffer transcends networking. But I agree with you, that's something we can discuss on the reviews.
Thanks
/Ilias
Quoted 24 lines · Ilias Apalodimas
Hi Jakub
[...]
Quoted 20 lines
Quoted 19 lines
Quoted 19 lines
struct bump { unsigned long _page_flags; unsigned long bump_magic; struct page_pool *bump_pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t bump_ref_count; unsigned int _page_type; atomic_t _refcount; };To netwrok guys, any thoughts on it?
To Willy, do I understand correctly your direction?Plus, it's a quite another issue but I'm curious, that is, what do you guys think about moving the bump allocator(= page pool) code from network to mm? I'd like to start on the work once gathering opinion from both Willy and network guys.
Quoted 7 lines
Quoted 3 lines
I don't see any benefit from moving page pool to MM. It is quite networking specific. But we can discuss this later. Moving code is trivial, it should not be the initial focus.
Random thoughts here until I look at the patches. The concept of devices doing DMA + recycling the used buffer transcends networking.
Do you know of any other subsystem which takes a page, splits it into two, and then uses each half independently for DMA and recycling. A typical packet is 1514 octets, so you can get two in a page.
Andrew
Quoted 7 lines · Andrew Lunn
Quoted 3 lines
Random thoughts here until I look at the patches. The concept of devices doing DMA + recycling the used buffer transcends networking.
Do you know of any other subsystem which takes a page, splits it into two, and then uses each half independently for DMA and recycling. A typical packet is 1514 octets, so you can get two in a page.
The mm/dmapool.c code is all about this.
Hi Andrew
Apologies for the late reply,
Quoted 30 lines · Andrew Lunn
Quoted 28 lines · Ilias Apalodimas
Hi Jakub
[...]
Quoted 23 lines
Quoted 12 lines
Quoted 12 lines
struct bump { unsigned long _page_flags; unsigned long bump_magic; struct page_pool *bump_pp; unsigned long _pp_mapping_pad; unsigned long dma_addr; atomic_long_t bump_ref_count; unsigned int _page_type; atomic_t _refcount; };Quoted 7 lines
Quoted 7 lines
To netwrok guys, any thoughts on it?
To Willy, do I understand correctly your direction?Plus, it's a quite another issue but I'm curious, that is, what do you guys think about moving the bump allocator(= page pool) code from network to mm? I'd like to start on the work once gathering opinion from both Willy and network guys.
I don't see any benefit from moving page pool to MM. It is quite networking specific. But we can discuss this later. Moving code is trivial, it should not be the initial focus.
Quoted 7 lines
Quoted 3 lines
Random thoughts here until I look at the patches. The concept of devices doing DMA + recycling the used buffer transcends networking.
Do you know of any other subsystem which takes a page, splits it into two, and then uses each half independently for DMA and recycling. A typical packet is 1514 octets, so you can get two in a page.
No, but OTOH the recycling is not somehow bound to having multiple fragments of a page. So I assumed more subsystems would benefit from not constantly re-allocating and re-mapping pages
Thanks
/Ilias
Quoted 2 lines
Andrew