From: Linus Torvalds > Sent: 26 July 2024 19:24 > > On Fri, 26 Jul 2024 at 11:13, Lorenzo Stoakes > <lorenzo.stoakes@oracle.com> 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. - 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 suspect just reordering to: extra_pages = min3(extra_pages, max_pages - max_pfn, EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM))); will have a similar effect. I'll try to do a v2 of the patchset tomorrow. - I'll leave __is_constexpr() with its current define (for now). - Fix the issue the build robot fount. - Fix the typo in min3(). - use auto_type for min/max functions. Once that lot is in I'll do some further changes for 'next'. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
On Fri, 26 Jul 2024 at 14:33, David Laight <David.Laight@aculab.com> wrote: > > I suspect just reordering to: > extra_pages = min3(extra_pages, max_pages - max_pfn, > EXTRA_MEM_RATIO * min(max_pfn, PFN_DOWN(MAXMEM))); > will have a similar effect. That's disgusting. No, we're not adding random "the ordering of min3() matters subtly for expansion size" crap. We're simplifying the sub-expressions, and fixing the problem that way. Linus
© 2016 - 2024 Red Hat, Inc.