On 2024/4/17 0:22, Alexander H Duyck wrote:
On Mon, 2024-04-15 at 21:19 +0800, Yunsheng Lin wrote:
quoted
The '(PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE)' case is for the
system with page size less than 32KB, which is 0x8000 bytes
requiring 16 bits space, change 'size' to 'size_mask' to avoid
using the MSB, and change 'pfmemalloc' field to reuse the that
MSB, so that we remove the orginal space needed by 'pfmemalloc'.
For another case, the MSB of 'offset' is reused for 'pfmemalloc'.
Signed-off-by: Yunsheng Lin <redacted>
---
include/linux/page_frag_cache.h | 13 ++++++++-----
mm/page_frag_cache.c | 5 +++--
2 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/include/linux/page_frag_cache.h b/include/linux/page_frag_cache.h
index fe5faa80b6c3..40a7d6da9ef0 100644
--- a/include/linux/page_frag_cache.h
+++ b/include/linux/page_frag_cache.h
@@ -12,15 +12,16 @@ struct page_frag_cache {
void *va;
#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE)
__u16 offset;
- __u16 size;
+ __u16 size_mask:15;
+ __u16 pfmemalloc:1;
#else
- __u32 offset;
+ __u32 offset:31;
+ __u32 pfmemalloc:1;
#endif
This seems like a really bad idea. Using a bit-field like this seems
like a waste as it means that all the accesses now have to add
additional operations to access either offset or size. It wasn't as if
this is an oversized struct, or one that we are allocating a ton of. As
such I am not sure why we need to optmize for size like this.
For the old 'struct page_frag' use case, there is one 'struct page_frag'
for every socket and task_struct, there may be tens of thousands of
them even in a 32 bit sysmem, which might mean a lof of memory even for
a single byte saving, see patch 13.
quoted
/* we maintain a pagecount bias, so that we dont dirty cache line
* containing page->_refcount every time we allocate a fragment.
*/
unsigned int pagecnt_bias;
- bool pfmemalloc;
};