Date:	Sat, 6 Sep 2008 16:33:18 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Yasunori Goto <y-goto@...fujitsu.com>
Cc:	Andi Kleen <andi@...stfloor.org>, Gary Hade <garyhade@...ibm.com>,
	linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
	Badari Pulavarty <pbadari@...ibm.com>,
	Mel Gorman <mel@....ul.ie>, Chris McDermott <lcm@...ibm.com>,
	linux-kernel@...r.kernel.org, x86@...nel.org
Subject: Re: [PATCH] [RESEND] x86_64: add memory hotremove config option


* Yasunori Goto <y-goto@...fujitsu.com> wrote:

> I don't think its driver is almighty. IIRC, balloon driver can be 
> cause of fragmentation for 24-7 system.
> 
> In addition, I have heard that memory hotplug would be useful for 
> reducing of power consumption of DIMM.
> 
> I have to admit that memory hotplug has many issues, but I would like 
> to solve them step by step.

What would be nice is to insert the information both during bootup and 
in /proc/meminfo and 'free' output that hot-removable memory segments 
are not generic free memory, it's currently a limited resource that 
might or might not be sufficient to serve a given workload.

Perhaps even exclude it from 'total' memory reported by meminfo - to be 
on the safe side of user expectations. In terms of user-space memory it 
is already generic swappable memory but in terms of kernel-space 
allocations it is not.

As i said it earlier in the thread, i certainly have no objections from 
the x86 maintenance side - nothing is worse than a generic kernel 
feature only available on certain less frequently used platforms. Memory 
hotplug has been available for some time in the MM and it's not really 
causing any maintenance trouble at the moment and it is not enabled by 
default either.

Having said that, i have my doubts about its generic utility (the power 
saving aspects are likely not realizable - nobody really wants DIMMs to 
just sit there unused and the cost of dynamic migration is just 
horrendous) - but as long as it's opt-in there's no reason to limit the 
availability of an in-kernel feature artificially.

Removing those limitations of kernel-space allocations should indeed be 
done in baby steps - and whether it's worth turning such memory into 
completely generic kernel memory is an open question.

But the fact that a piece of memory is not fully generic is no reason 
not to allow users to create special, capability-limited RAM resources 
like they can already do via hugetlbfs or ramfs, as long as the the 
capability limitations are advertised clearly.

Yes, memory hotplug has limitations we all understand, but still it's an 
arguably useful feature in some circumstances. If we never give a 
feature a chance to evolve on the main Linux platform that 90%+ of our 
users use it wont ever be truly useful.

Please send the new patches against -git or -tip and we can put them 
into a separate standalone feature topic and can test it on various x86 
boxes and send them towards linux-next if Andrew agrees with that 
process too.

Btw., it would be nice if memory hotplug had a self-test that could be 
activated from the .config and would run autonomously (a bit like 
rcu-torture): it would mark say 10% of all RAM as hot-pluggable during 
bootup and would periodically hot-plug and hot-unplug that memory, every 
10 seconds or 30 seconds or so, transparently. That would also test the 
x86 architecture's pagetable init code, the page migration code, etc. 
(Disabled by default and dependent on DEBUG_KERNEL && EXPERIMENTAL.)

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists