From: Andrew Morton <akpm@linux-foundation.org> To: mike.yoknis@hp.com Cc: Mel Gorman <mgorman@suse.de>, mingo@redhat.com, linux-arch@vger.kernel.org, mmarek@suse.cz, tglx@linutronix.de, hpa@zytor.com, arnd@arndb.de, sam@ravnborg.org, minchan@kernel.org, kamezawa.hiroyu@jp.fujitsu.com, mhocko@suse.cz, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2] mm: memmap_init_zone() performance improvement Date: Tue, 30 Oct 2012 15:31:57 -0700 [thread overview] Message-ID: <20121030153157.70279408.akpm@linux-foundation.org> (raw) In-Reply-To: <1351291667.6504.13.camel@MikesLinux.fc.hp.com> On Fri, 26 Oct 2012 16:47:47 -0600 Mike Yoknis <mike.yoknis@hp.com> wrote: > memmap_init_zone() loops through every Page Frame Number (pfn), > including pfn values that are within the gaps between existing > memory sections. The unneeded looping will become a boot > performance issue when machines configure larger memory ranges > that will contain larger and more numerous gaps. > > The code will skip across invalid pfn values to reduce the > number of loops executed. > So I was wondering how much difference this makes. Then I see Mel already asked and was answered. The lesson: please treat a reviewer question as a sign that the changelog needs more information! I added this text to the changelog: : We have what we call an "architectural simulator". It is a computer : program that pretends that it is a computer system. We use it to test the : firmware before real hardware is available. We have booted Linux on our : simulator. As you would expect it takes longer to boot on the simulator : than it does on real hardware. : : With my patch - boot time 41 minutes : Without patch - boot time 94 minutes : : These numbers do not scale linearly to real hardware. But indicate to me : a place where Linux can be improved. > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -3857,8 +3857,11 @@ void __meminit memmap_init_zone(unsigned long > size, int nid, unsigned long zone, > * exist on hotplugged memory. > */ > if (context == MEMMAP_EARLY) { > - if (!early_pfn_valid(pfn)) > + if (!early_pfn_valid(pfn)) { > + pfn = ALIGN(pfn + MAX_ORDER_NR_PAGES, > + MAX_ORDER_NR_PAGES) - 1; > continue; > + } > if (!early_pfn_in_nid(pfn, nid)) > continue; > } So what is the assumption here? That each zone's first page has a pfn which is a multiple of MAX_ORDER_NR_PAGES? That seems reasonable, but is it actually true, for all architectures and for all time? Where did this come from? -- 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>
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org> To: mike.yoknis@hp.com Cc: Mel Gorman <mgorman@suse.de>, mingo@redhat.com, linux-arch@vger.kernel.org, mmarek@suse.cz, tglx@linutronix.de, hpa@zytor.com, arnd@arndb.de, sam@ravnborg.org, minchan@kernel.org, kamezawa.hiroyu@jp.fujitsu.com, mhocko@suse.cz, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2] mm: memmap_init_zone() performance improvement Date: Tue, 30 Oct 2012 15:31:57 -0700 [thread overview] Message-ID: <20121030153157.70279408.akpm@linux-foundation.org> (raw) Message-ID: <20121030223157.REOADeo01uewYyUUN36pOfCYkcfEWcwH2RpTnqbeLjU@z> (raw) In-Reply-To: <1351291667.6504.13.camel@MikesLinux.fc.hp.com> On Fri, 26 Oct 2012 16:47:47 -0600 Mike Yoknis <mike.yoknis@hp.com> wrote: > memmap_init_zone() loops through every Page Frame Number (pfn), > including pfn values that are within the gaps between existing > memory sections. The unneeded looping will become a boot > performance issue when machines configure larger memory ranges > that will contain larger and more numerous gaps. > > The code will skip across invalid pfn values to reduce the > number of loops executed. > So I was wondering how much difference this makes. Then I see Mel already asked and was answered. The lesson: please treat a reviewer question as a sign that the changelog needs more information! I added this text to the changelog: : We have what we call an "architectural simulator". It is a computer : program that pretends that it is a computer system. We use it to test the : firmware before real hardware is available. We have booted Linux on our : simulator. As you would expect it takes longer to boot on the simulator : than it does on real hardware. : : With my patch - boot time 41 minutes : Without patch - boot time 94 minutes : : These numbers do not scale linearly to real hardware. But indicate to me : a place where Linux can be improved. > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -3857,8 +3857,11 @@ void __meminit memmap_init_zone(unsigned long > size, int nid, unsigned long zone, > * exist on hotplugged memory. > */ > if (context == MEMMAP_EARLY) { > - if (!early_pfn_valid(pfn)) > + if (!early_pfn_valid(pfn)) { > + pfn = ALIGN(pfn + MAX_ORDER_NR_PAGES, > + MAX_ORDER_NR_PAGES) - 1; > continue; > + } > if (!early_pfn_in_nid(pfn, nid)) > continue; > } So what is the assumption here? That each zone's first page has a pfn which is a multiple of MAX_ORDER_NR_PAGES? That seems reasonable, but is it actually true, for all architectures and for all time? Where did this come from?
next prev parent reply other threads:[~2012-10-30 22:31 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-10-03 14:56 [PATCH] mm: memmap_init_zone() performance improvement Mike Yoknis 2012-10-06 23:59 ` Ni zhan Chen 2012-10-06 23:59 ` Ni zhan Chen 2012-10-08 15:16 ` Mel Gorman 2012-10-08 15:16 ` Mel Gorman 2012-10-09 0:42 ` Ni zhan Chen 2012-10-09 0:42 ` Ni zhan Chen 2012-10-09 14:56 ` Mike Yoknis 2012-10-19 19:53 ` Mike Yoknis 2012-10-20 8:29 ` Mel Gorman 2012-10-20 8:29 ` Mel Gorman 2012-10-24 15:47 ` Mike Yoknis 2012-10-24 15:47 ` Mike Yoknis 2012-10-25 9:44 ` Mel Gorman 2012-10-26 22:47 ` [PATCH v2] " Mike Yoknis 2012-10-26 22:47 ` Mike Yoknis 2012-10-30 22:31 ` Andrew Morton [this message] 2012-10-30 22:31 ` Andrew Morton 2012-10-30 15:14 ` [PATCH] " Dave Hansen 2012-10-30 15:14 ` Dave Hansen 2012-11-06 16:03 ` Mike Yoknis 2012-11-06 16:03 ` Mike Yoknis 2012-12-18 23:03 ` Andrew Morton
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20121030153157.70279408.akpm@linux-foundation.org \ --to=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=hpa@zytor.com \ --cc=kamezawa.hiroyu@jp.fujitsu.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-kbuild@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mgorman@suse.de \ --cc=mhocko@suse.cz \ --cc=mike.yoknis@hp.com \ --cc=minchan@kernel.org \ --cc=mingo@redhat.com \ --cc=mmarek@suse.cz \ --cc=sam@ravnborg.org \ --cc=tglx@linutronix.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).