[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] RE: [RFC] transcendent memory for Linux
> 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |