From: Mel Gorman <mel@csn.ul.ie> To: Russell King - ARM Linux <linux@arm.linux.org.uk> Cc: Minchan Kim <minchan.kim@gmail.com>, Kukjin Kim <kgene.kim@samsung.com>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, ben-linux@fluff.org Subject: Re: About SECTION_SIZE_BITS for Sparsemem Date: Wed, 14 Jul 2010 14:14:15 +0100 [thread overview] Message-ID: <20100714131415.GC13117@csn.ul.ie> (raw) In-Reply-To: <20100714085918.GB9115@n2100.arm.linux.org.uk> On Wed, Jul 14, 2010 at 09:59:18AM +0100, Russell King - ARM Linux wrote: > On Tue, Jul 13, 2010 at 09:32:50PM +0100, Mel Gorman wrote: > > On Tue, Jul 13, 2010 at 06:37:44PM +0100, Russell King - ARM Linux wrote: > > > You're saying that MAX_PHYSMEM_BITS=29 SECTION_SIZE_BITS=26 is wrong. > > > > > > > Not wrong. It's fine as long as you're ok with some unnecessary memmap > > being allocated. There is wastage of memory but functionally it'll be > > fine with existing sparsemem and the assumptions it makes. > > > > Obviously you're not ok with this wastage or this discussion would not even > > be happening and with SECTION_SIZE_BITS=26, there is quite a bit of wastage. > > Absolutely I'm not ok with this wastage - it's 127 + 127 + 64 pages, or > 1.2MB - that's 4% of system memory wasted in stuff which isn't going to > be used. > > Moreover, the mem_map array for each populated bank is 512K - which is > the size of the RAM in the first two banks. At that point, there's > absolutely no point in populating them. The overhead of populating > those banks exactly equals the gain from populating them. > > Sparsemem is absolutely absurd in this requirement - it can't handle > sparse memory efficiently without wasting lots of memory in the > process. > I wasn't around when sparsemem was designed, but I strongly suspect it wasn't considered that a bank would only be 512K. The requirement of a section being fully populated to allow pfn_valid to be very cheap still seems very reasonable to me in the majority of cases. It's just no ok in ARMs case because of the size of banks. > > I haven't researched this so apologies if it turns out to be stupid but > > I think the bit SECTION_MAP_LAST_BIT is actually unused and should be > > safe to use. Has the option being considered of using this bit to mean > > "section has holes punched in it". If set, the architecture must provide > > an additional arch_holey_section_pfn_valid() that does additional checking > > based on information sparsemem doesn't have? This would avoid the worst of > > the performance issues of making pfn_valid() slower without increasing the > > size of mem_section. > > As I've already said, how about just allowing pfn_valid() to be overridden > by architectures, even for the sparsemem case. If nothing else pans out, I won't resist that approach. It's not my No.1 perference because it results in SparseMem-on-ARM behaving one way and SparseMem-on-everything-else behaving another with respect to pfn_valid(). I'd prefer that an architecture-specific pfn_valid() only be called for the sections that are known to have holes punched in them. > We have a perfectly good > pfn_valid() implementation that'll work across the board, and will fix > this issue. > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab
WARNING: multiple messages have this Message-ID (diff)
From: mel@csn.ul.ie (Mel Gorman) To: linux-arm-kernel@lists.infradead.org Subject: About SECTION_SIZE_BITS for Sparsemem Date: Wed, 14 Jul 2010 14:14:15 +0100 [thread overview] Message-ID: <20100714131415.GC13117@csn.ul.ie> (raw) In-Reply-To: <20100714085918.GB9115@n2100.arm.linux.org.uk> On Wed, Jul 14, 2010 at 09:59:18AM +0100, Russell King - ARM Linux wrote: > On Tue, Jul 13, 2010 at 09:32:50PM +0100, Mel Gorman wrote: > > On Tue, Jul 13, 2010 at 06:37:44PM +0100, Russell King - ARM Linux wrote: > > > You're saying that MAX_PHYSMEM_BITS=29 SECTION_SIZE_BITS=26 is wrong. > > > > > > > Not wrong. It's fine as long as you're ok with some unnecessary memmap > > being allocated. There is wastage of memory but functionally it'll be > > fine with existing sparsemem and the assumptions it makes. > > > > Obviously you're not ok with this wastage or this discussion would not even > > be happening and with SECTION_SIZE_BITS=26, there is quite a bit of wastage. > > Absolutely I'm not ok with this wastage - it's 127 + 127 + 64 pages, or > 1.2MB - that's 4% of system memory wasted in stuff which isn't going to > be used. > > Moreover, the mem_map array for each populated bank is 512K - which is > the size of the RAM in the first two banks. At that point, there's > absolutely no point in populating them. The overhead of populating > those banks exactly equals the gain from populating them. > > Sparsemem is absolutely absurd in this requirement - it can't handle > sparse memory efficiently without wasting lots of memory in the > process. > I wasn't around when sparsemem was designed, but I strongly suspect it wasn't considered that a bank would only be 512K. The requirement of a section being fully populated to allow pfn_valid to be very cheap still seems very reasonable to me in the majority of cases. It's just no ok in ARMs case because of the size of banks. > > I haven't researched this so apologies if it turns out to be stupid but > > I think the bit SECTION_MAP_LAST_BIT is actually unused and should be > > safe to use. Has the option being considered of using this bit to mean > > "section has holes punched in it". If set, the architecture must provide > > an additional arch_holey_section_pfn_valid() that does additional checking > > based on information sparsemem doesn't have? This would avoid the worst of > > the performance issues of making pfn_valid() slower without increasing the > > size of mem_section. > > As I've already said, how about just allowing pfn_valid() to be overridden > by architectures, even for the sparsemem case. If nothing else pans out, I won't resist that approach. It's not my No.1 perference because it results in SparseMem-on-ARM behaving one way and SparseMem-on-everything-else behaving another with respect to pfn_valid(). I'd prefer that an architecture-specific pfn_valid() only be called for the sections that are known to have holes punched in them. > We have a perfectly good > pfn_valid() implementation that'll work across the board, and will fix > this issue. > -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab
next prev parent reply other threads:[~2010-07-14 13:14 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-07-12 8:32 About SECTION_SIZE_BITS for Sparsemem Kukjin Kim 2010-07-12 8:32 ` Kukjin Kim 2010-07-12 9:35 ` Kyungmin Park 2010-07-12 9:35 ` Kyungmin Park 2010-07-12 9:58 ` Kukjin Kim 2010-07-12 9:58 ` Kukjin Kim 2010-07-12 10:08 ` Kyungmin Park 2010-07-12 10:08 ` Kyungmin Park 2010-07-12 10:13 ` Russell King - ARM Linux 2010-07-12 10:13 ` Russell King - ARM Linux 2010-07-12 9:52 ` Minchan Kim 2010-07-12 9:52 ` Minchan Kim 2010-07-12 10:13 ` Kukjin Kim 2010-07-12 10:13 ` Kukjin Kim 2010-07-12 10:35 ` Minchan Kim 2010-07-12 10:35 ` Minchan Kim 2010-07-13 0:25 ` KAMEZAWA Hiroyuki 2010-07-13 0:25 ` KAMEZAWA Hiroyuki 2010-07-13 1:53 ` KAMEZAWA Hiroyuki 2010-07-13 1:53 ` KAMEZAWA Hiroyuki 2010-07-13 18:31 ` Russell King - ARM Linux 2010-07-13 18:31 ` Russell King - ARM Linux 2010-07-13 2:05 ` Minchan Kim 2010-07-13 2:05 ` Minchan Kim 2010-07-13 3:03 ` KAMEZAWA Hiroyuki 2010-07-13 3:03 ` KAMEZAWA Hiroyuki 2010-07-13 9:28 ` Mel Gorman 2010-07-13 9:28 ` Mel Gorman 2010-07-13 9:38 ` Russell King - ARM Linux 2010-07-13 9:38 ` Russell King - ARM Linux 2010-07-13 9:26 ` Mel Gorman 2010-07-13 9:26 ` Mel Gorman 2010-07-13 9:38 ` Russell King - ARM Linux 2010-07-13 9:38 ` Russell King - ARM Linux 2010-07-13 9:50 ` Mel Gorman 2010-07-13 9:50 ` Mel Gorman 2010-07-13 17:37 ` Russell King - ARM Linux 2010-07-13 17:37 ` Russell King - ARM Linux 2010-07-13 20:32 ` Mel Gorman 2010-07-13 20:32 ` Mel Gorman 2010-07-13 23:59 ` Minchan Kim 2010-07-13 23:59 ` Minchan Kim 2010-07-14 8:49 ` Russell King - ARM Linux 2010-07-14 8:49 ` Russell King - ARM Linux 2010-07-14 11:04 ` Minchan Kim 2010-07-14 11:04 ` Minchan Kim 2010-07-14 20:49 ` Russell King - ARM Linux 2010-07-14 20:49 ` Russell King - ARM Linux 2010-07-16 0:07 ` Minchan Kim 2010-07-16 0:07 ` Minchan Kim 2010-07-14 8:59 ` Russell King - ARM Linux 2010-07-14 8:59 ` Russell King - ARM Linux 2010-07-14 13:14 ` Mel Gorman [this message] 2010-07-14 13:14 ` Mel Gorman 2010-07-12 10:45 ` Russell King - ARM Linux 2010-07-12 10:45 ` Russell King - ARM Linux 2010-07-12 12:28 ` Minchan Kim 2010-07-12 12:28 ` Minchan Kim 2010-07-12 12:42 ` Russell King - ARM Linux 2010-07-12 12:42 ` Russell King - ARM Linux
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=20100714131415.GC13117@csn.ul.ie \ --to=mel@csn.ul.ie \ --cc=ben-linux@fluff.org \ --cc=kamezawa.hiroyu@jp.fujitsu.com \ --cc=kgene.kim@samsung.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-samsung-soc@vger.kernel.org \ --cc=linux@arm.linux.org.uk \ --cc=minchan.kim@gmail.com \ /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 an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.