Re: [Xen-devel] yanked share, round 2

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 13 Jan 2006, at 23:02, King, Steven R wrote:

> We get these features:
> 1) A domU can never cause the Xen share pool to shrink.
> 2) The number of pages mappable by a DomU is bounded only by the DomU
> itself.
> 3) No page ownership problems.
> 4) We can have a nice share key ala SysV IPC semantics.
> 5) When no shares exist, the memory pool consumes no pages.
> 6) We leave Xen's heap alone.
>
> The first benefit is critical since DomU's are untrusted.  A downside 
> is
> that a platform with many DomU mappings will have many idle pages
> sitting in the pool.  Given all the benefits above, a very reasonable
> price to pay.
This is similar to ideas people have had for shared buffer cache 
without memory overcommitment. Seems to me that the Xen-level mechanism 
for doing the sharing could easily be identical, and the differences in 
interface, access control and other policy could be hidden in a share 
manager in a suitably-privileged domain.
 -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel