Messages in this thread | | | Date | Thu, 11 Sep 2008 10:56:38 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [Approach #2] [RFC][PATCH] Remove cgroup member from struct page |
| |
On Wed, 10 Sep 2008 18:47:25 -0700 Balbir Singh <balbir@linux.vnet.ibm.com> wrote:
> KAMEZAWA Hiroyuki wrote: > > On Wed, 10 Sep 2008 15:56:48 -0700 > > Dave Hansen <dave@linux.vnet.ibm.com> wrote: > > > >> On Wed, 2008-09-10 at 15:36 -0700, Balbir Singh wrote: > >>> Dave Hansen wrote: > >>>> On Tue, 2008-09-09 at 18:20 -0700, Balbir Singh wrote: > >>>>> + start = pgdat->node_start_pfn; > >>>>> + end = pgdat->node_start_pfn + pgdat->node_spanned_pages; > >>>>> + size = (end - start) * sizeof(struct page_cgroup); > >>>>> + printk("Allocating %lu bytes for node %d\n", size, n); > >>>>> + pcg_map[n] = alloc_bootmem_node(pgdat, size); > >>>>> + /* > >>>>> + * We can do smoother recovery > >>>>> + */ > >>>>> + BUG_ON(!pcg_map[n]); > >>>>> + return 0; > >>>>> } > >>>> This will really suck for sparse memory machines. Imagine a machine > >>>> with 1GB of memory at 0x0 and another 1GB of memory at 1TB up in the > >>>> address space. > >>>> > >>> I would hate to re-implement the entire sparsemem code :( > >>> Kame did suggest making the memory controller depend on sparsemem (to hook in > >>> from there for allocations) > >> Yeah, you could just make another mem_section member. Or, you could > >> work to abstract the sparsemem code so that other people can use it, or > >> maybe make it more dynamic so we can have multiple pfn->object lookups > >> in parallel. Adding the struct member is obviously easier. > >> > > Don't worry. I'll care sparse memory map and hotplug. > > But whether making this depends on SPARSEMEM or not is not fixed yet. > > I'll try generic one, at first. If it's dirty, start discussion about SPARSEMEM. > > > > (Honestly, I love sparsemem than others ;) > > My concern is that if we depend on sparsemem, then we force distros to turn on > sparsemem (which might be the default, but not on all architectures), we might > end up losing those architectures (w.r.t. turning on the memory controller) > where sparsemem is not the default on the distro. > Yes. I share your concern. Then, I'll try not-on-sparsemem version, at first.
Thanks, -Kame
| |