On Fri, 26 Jul 2024 at 11:13, Lorenzo Stoakes
<lorenzo.stoakes@xxxxxxxxxx> wrote:
>
> 5,447,539 ./arch/x86/xen/setup.o.pre
Can you perhaps do some kind of "max expansion" on all the
preprocessor files (you seem to have done it by changing the ".c.o"
rule to just spit it out as "o.pre", which sounds fine).
For example, this trivial patch seems to fix the setup.c expansion by
about an order of magnitude (ie 50M -> 5M).
Entirely untested, but looks ObviouslyCorrect(tm) to me.
Linus
Linus
arch/x86/xen/setup.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
index a0c3e77e3d5b..806ddb2391d9 100644
--- a/arch/x86/xen/setup.c
+++ b/arch/x86/xen/setup.c
@@ -690,6 +690,7 @@ char * __init xen_memory_setup(void)
struct xen_memory_map memmap;
unsigned long max_pages;
unsigned long extra_pages = 0;
+ unsigned long maxmem_pages;
int i;
int op;
@@ -761,8 +762,8 @@ char * __init xen_memory_setup(void)
* Make sure we have no memory above max_pages, as this area
* isn't handled by the p2m management.
*/
- extra_pages = min3(EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM)),
- extra_pages, max_pages - max_pfn);
+ maxmem_pages = EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM));
+ extra_pages = min3(maxmem_pages, extra_pages, max_pages - max_pfn);
i = 0;
addr = xen_e820_table.entries[0].addr;
size = xen_e820_table.entries[0].size;
