| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
[Xen-devel] RE: [RFC] transcendent memory for Linux
|
To: |
Pavel Machek <pavel@xxxxxx> |
|
Subject: |
[Xen-devel] RE: [RFC] transcendent memory for Linux |
|
From: |
Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> |
|
Date: |
Mon, 29 Jun 2009 14:13:56 -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, 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, 06 Jul 2009 07:58:55 -0700 |
|
Envelope-to: |
www-data@xxxxxxxxxxxxxxxxxxx |
|
In-reply-to: |
<20090629203619.GA6611@xxxxxxxxxx> |
|
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 |
> > It is documented currently at:
> >
> > http://oss.oracle.com/projects/tmem/documentation/api/
> >
> > (just noticed I still haven't posted version 0.0.2 which
> > has a few minor changes).
> >
> > I will add a briefer description of this API in Documentation/
>
> Please do.
OK, will do.
> At least TMEM_NEW_POOL() looks quite ugly. Why uuid? Mixing flags into
> size argument is strange.
The uuid is only used for shared pools. If two different
"tmem clients" (guests) agree on a 128-bit "shared secret",
they can share a tmem pool. For ocfs2, the 128-bit uuid in
the on-disk superblock is used for this purpose to implement
shared precache. (Pages evicted by one cluster node
can be used by another cluster node that co-resides on
the same physical system.)
The (page)size argument is always fixed (at PAGE_SIZE) for
any given kernel. The underlying implementation can
be capable of supporting multiple pagesizes.
So for the basic precache and preswap uses, "new pool"
has a very simple interface.
> > It is in-kernel only because some of the operations have
> > a parameter that is a physical page frame number.
>
> In-kernel API is probably better described as function prototypes.
Good idea. I will do that.
Thanks,
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home