xen-devel
[Xen-devel] RE: [RFC] transcendent memory for Linux
To: |
Linus Walleij <linus.ml.walleij@xxxxxxxxx> |
Subject: |
[Xen-devel] RE: [RFC] transcendent memory for Linux |
From: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
Date: |
Mon, 29 Jun 2009 07:44:50 -0700 (PDT) |
Cc: |
npiggin@xxxxxxx, akpm@xxxxxxxx, jeremy@xxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, tmem-devel@xxxxxxxxxxxxxx, alan@xxxxxxxxxxxxxxxxxxx, linux-mm@xxxxxxxxx, kurt.hackel@xxxxxxxxxx, Rusty Russell <rusty@xxxxxxxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx, dave.mccracken@xxxxxxxxxx, linux-embedded@xxxxxxxxxxxxxxx, Marcelo Tosatti <mtosatti@xxxxxxxxxx>, Himanshu Raj <rhim@xxxxxxxxxxxxx>, sunil.mushran@xxxxxxxxxx, Avi Kivity <avi@xxxxxxxxxx>, Martin Schwidefsky <schwidefsky@xxxxxxxxxx>, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx>, chris.mason@xxxxxxxxxx, Rik |
Delivery-date: |
Mon, 29 Jun 2009 08:09:08 -0700 |
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
In-reply-to: |
<63386a3d0906270618h5be01265v759f5acd1f49682f@xxxxxxxxxxxxxx> |
List-help: |
<mailto:xen-devel-request@lists.xensource.com?subject=help> |
List-id: |
Xen developer discussion <xen-devel.lists.xensource.com> |
List-post: |
<mailto:xen-devel@lists.xensource.com> |
List-subscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe> |
List-unsubscribe: |
<http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe> |
Sender: |
xen-devel-bounces@xxxxxxxxxxxxxxxxxxx |
> From: Linus Walleij [mailto:linus.ml.walleij@xxxxxxxxx]
> Sent: Saturday, June 27, 2009 7:19 AM
> Subject: Re: [RFC] transcendent memory for Linux
>
> > We call this latter class "transcendent memory" and it
> > provides an interesting opportunity to more efficiently
> > utilize RAM in a virtualized environment. However this
> > "memory but not really memory" may also have applications
> > in NON-virtualized environments, such as hotplug-memory
> > deletion, SSDs, and page cache compression. Others have
> > suggested ideas such as allowing use of highmem memory
> > without a highmem kernel, or use of spare video memory.
>
> Here is what I consider may be a use case from the embedded
> world: we have to save power as much as possible, so we need
> to shut off entire banks of memory.
>
> Currently people do things like put memory into self-refresh
> and then sleep, but for long lapses of time you would
> want to compress memory towards lower addresses and
> turn as many banks as possible off.
>
> So we have something like 4x16MB banks of RAM = 64MB RAM,
> and the most necessary stuff easily fits in one of them.
> If we can shut down 3x16MB we save 3 x power supply of the
> RAMs.
>
> However in embedded we don't have any swap, so we'd need
> some call that would attempt to remove a memory by paging
> out code and data that has been demand-paged in
> from the FS but no dirty pages, these should instead be
> moved down to memory which will be retained, and the
> call should fail if we didn't succeed to migrate all
> dirty pages.
>
> Would this be possible with transcendent memory?
Yes, I think this would work nicely as a use case for tmem.
As Avi points out, you could do this with memory defragmentation,
but if you know in advance that you will be frequently
powering on and off a bank of RAM, you could put only
ephemeral memory into it (enforced by a kernel policy and
the tmem API), then defragmentation (and compression towards
lower addresses) would not be necessary, and you could power
off a bank with no loss of data.
One issue though: I would guess that copying pages of memory
could be very slow in an inexpensive embedded processor.
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread> |
- [Xen-devel] [RFC PATCH 3/4] tmem: preswap implementation (layered on tmem), (continued)
|
|
|