Re: [RFCv1 3/6] PASR: mm: Integrate PASR in Buddy allocator

[Mel Gorman]

On Tue, Jan 31, 2012 at 07:55:47PM +0100, Maxime Coquelin wrote:
> >>To avoid calling pasr_kget/kput() directly in page_alloc.c, do you
> >>think adding some arch specific hooks when a page is inserted or
> >>removed from the free lists could be acceptable?
> >It's not the name that is the problem, I'm strongly against any hook
> >that can delay the page allocator for arbitrary lengths of time like
> >this. I am open to being convinced otherwise but for me PASR would
> >need to demonstrate large savings for a wide variety of machines and
> >the alternatives would have to be considered and explained why they
> >would be far inferior or unsuitable.
>
> Ok Mel, I understand your point of view.
> 
> The goal of this RFC patch set was to collect comments, so I'm glad
> to get your opinion.
> I propose to forget the patch in the Buddy allocator.
> 

Or at least tag it as "this should have an alternative"

> >For example - it seems like this could be also be done with a
> >balloon driver instead of page allocator hooks. A governer would
> >identify when the machine was under no memory pressure or triggered
> >from userspace. To power down memory, it would use page reclaim and
> >page migration to allocate large contiguous ranges of memory - CMA
> >could potentially be adapted when it gets merged to save a lot of
> >implementation work. The governer should register a slab shrinker
> >so that under memory pressure it gets called so it can shrink the
> >ballon, power the DIMMS back up and free the memory back to the
> >buddy allocator. This would keep all the cost out of the allocator
> >paths and move the cost to when the machine is either idle (in the
> >case of powering down) or under memory pressure (where the cost of
> >powering up will be small in comparison to the overall cost of the
> >page reclaim operation).
> >
>
> This is very interesting.
> I know Linaro plans to work on DDR power management topic.
> One of the options they envisage is to use the Memory Hotplug feature.
> However, the main problem with Memory Hotplug is to handle the
> memory pressure, i.e. when to re-plug the memory sections.

heh, I was originally going to suggest the Memory Hotplug feature until
I ran into the problem of how to bring the memory back. Technically,
it could *also* use a shrinker and keep track of the memory it
offlined. It would work on a similar principal to the balloon but I
was worried that the cost of offlining and onlining memory would be
too high for PASR. There was also the problem that it would require
SPARSEMEM and would also require that you grew/shrunk memory in ranges
of the section size which might be totally different to PASR.

> Your proposal address this issue. I don't know if such a driver
> could be done in the Linaro scope.
> 

Beats me.

> Anyway, even with a balloon driver, I think the PASR framework could
> be suitable to keep an "hardware" view of the memory layout (dies,
> banks, segments...).

Oh yes, the balloon driver would still need this information!

> Moreover, this framework is designed to also support some physically
> contiguous memory allocators (such as hwmem and pmem).
> 

Not being familiar with hwmem or pmem, I can't be 100% certain but
superficially, I would expect that the same balloon driver could be used
for hwmem and pmem. The main difference between this balloon driver and
others will be how it selects pages to add to the balloon.

There are existing balloon drivers that you may or may not be able to
leverage. There is some talk that KVM people want to be able to balloon
2M contiguous pages. If this was ever implemented, it's possible that
you could reuse it for PASR so keep an eye out for it.

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