On Thu, 26 Aug 2010 06:01:56 +0200
Micha? Nazarewicz [off-list ref] wrote:

KAMEZAWA Hiroyuki [off-list ref] wrote:

quoted

128MB...too big ? But it's depend on config.

On embedded systems it may be like half of the RAM.  Or a quarter.  So bigger
granularity could be desired on some platforms.

quoted

IBM's ppc guys used 16MB section, and recently, a new interface to shrink
the number of /sys files are added, maybe usable.

Something good with this approach will be you can create "cma" memory
before installing driver.

That's how CMA works at the moment.  But if I understand you correctly, what
you are proposing would allow to reserve memory *at* *runtime* long after system
has booted.  This would be a nice feature as well though.

Yes, my proposal is that. 

quoted

But yes, complicated and need some works.

quoted

Ah, I need to clarify what I want to say.

With compaction, it's helpful, but you can't get contiguous memory larger
than MAX_ORDER, I think. To get memory larger than MAX_ORDER on demand,
memory hot-plug code has almost all necessary things.

I'll try to look at it then.

mm/memory_hotplug.c::offline_pages() does

	1. disallow new allocation of memory in [start_pfn...end_pfn)
	2. move all LRU pages to other regions than [start_pfn...end_pfn)
	3. finally, mark all pages as PG_reserved (see __offline_isolated_pages())

What's required for cma will be
	a. remove _section_ limitation, which is done as BUG_ON().
	b. replace 'step 3' with cma code.

Maybe you can do similar just using compaction logic. The biggest difference will
be 'step 1'.

quoted

BTW, just curious...the memory for cma need not to be saved at
hibernation ? Or drivers has to write its own hibernation ops by driver suspend
udev or some ?

Hibernation was not considered as of yet but I think it's device driver's
responsibility more then CMA's especially since it may make little sense to save
some of the buffers -- ie. no need to keep a frame from camera since it'll be
overwritten just after system wakes up from hibernation.  It may also be better
to stop playback and resume it later on rather than trying to save decoder's
state.  Again though, I haven't thought about hibernation as of yet.

Hmm, ok, use-case dependent and it's a job of a driver.

Thanks,
-Kame