[Ksummit-2013-discuss] [ATTEND] Linux VM Infrastructure to support Memory Power Management

Matthew Wilcox willy6545 at gmail.com
Sat Jul 20 17:01:59 UTC 2013


This requirement dovetails nicely with persistent RAM changes we might like
to consider. PRAM is generally usable as DRAM, but there may be penalties
to consider (depending on the technology in use) such as limited lifetime
writes, greater read latency, unpredictable read latency, limited write
bandwidth, write disturbs, and probably a few other things.

But it may still be advantageous to use it rather than swapping.
On 2013-07-19 6:50 PM, "Dave Hansen" <dave at sr71.net> wrote:

> On 07/18/2013 10:43 PM, Srivatsa S. Bhat wrote:
> > So, we could implement the base infrastructure for "region-awareness" in
> > the Linux VM and leave it upto a higher-level userspace policy to exploit
> > that feature for various usecases, such as influencing the region-aware
> > allocations/reclaim/compaction with a goal to effect power-savings, or to
> > use it for RAS reasons like you pointed out above.
>
> We've been in a nice honeymoon period with hardware where most any RAM
> on the system can be used for just about any purpose.  Yeah, there were
> NUMA effects, but if you need an allocation _and_ there's free memory
> you can almost always get it make use of it.  Free RAM is wasted RAM
> after all.
>
> Both Tony's and Srivatsa's use cases mean that this "allocate anywhere"
> approach is going away since we've now got sets of requirements that
> trump it.
>
> I'm not sure if this is the best KS topic, or whether it's better dealt
> with at Plumbers or an MM summit.  It's definitely something we've got
> to get in to people's heads though.
> _______________________________________________
> Ksummit-2013-discuss mailing list
> Ksummit-2013-discuss at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-2013-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/ksummit-2013-discuss/attachments/20130720/13adc262/attachment.html>


More information about the Ksummit-2013-discuss mailing list