Re: [PATCHv2 3/4] mm: pack compound_dtor and compound_order into one word in struct page
From: Michal Hocko <mhocko@kernel.org>
Date: 2015-08-18 15:43:07
Also in:
lkml
On Mon 17-08-15 18:09:04, Kirill A. Shutemov wrote:
The patch halves space occupied by compound_dtor and compound_order in struct page. For compound_order, it's trivial long -> int/short conversion. For get_compound_page_dtor(), we now use hardcoded table for destructor lookup and store its index in the struct page instead of direct pointer to destructor. It shouldn't be a big trouble to maintain the table: we have only two destructor and NULL currently. This patch free up one word in tail pages for reuse. This is preparation for the next patch. Signed-off-by: Kirill A. Shutemov <redacted>
Reviewed-by: Michal Hocko <mhocko@suse.com> [...]
quoted hunk ↗ jump to hunk
@@ -145,8 +143,13 @@ struct page { */ /* First tail page of compound page */ struct { - compound_page_dtor *compound_dtor; - unsigned long compound_order; +#ifdef CONFIG_64BIT + unsigned int compound_dtor; + unsigned int compound_order; +#else + unsigned short int compound_dtor; + unsigned short int compound_order; +#endif };
Why do we need this ifdef? We can go with short for both 32b and 64b AFAICS. We do not use compound_order for anything else than the order, right? While I am looking at this, it seems we are jugling with type for order quite a lot - int, unsing int and even unsigned long. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>