Re: [Xen-devel] A question no one can answer

["Dan Doucette" <doucette.daniel@xxxxxxxxx>]

Hello Robert and others,

 

Below is a link to a presentation given at a conference last summer, where the authors used cache colour allocation schemes to limit L2 cache overuse by an application. 

If your goal is to create a fair memory share per-guest (bandwidth or otherwise), you may want to consider the possibility of managing it from a level closer to the CPU.

 

http://www.ideal.ece.ufl.edu/workshops/wiosca07/P4Slides.pdf

 

Dan.

 

 

On Fri, Feb 15, 2008 at 5:05 AM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:

On Thu, 14 Feb 2008 22:24:18 -0500

"Robert Stober" <rstober@xxxxxxxxxxxx> wrote:

> Weiming,
>
> I agree that it is very hard, and that no one has done it. But
> nevertheless I suggest the following question to the Xen developers:
>
> Given the fact that memory bandwidth is shared amongst multiple cores on
> a single die, assume that one VM is running on each core. What is to
> stop one VM from saturating the memory bus, causing reduced performance
> of all the other VMs? This is the general multi-core problem, not
> specific to Xen. But it affects Xen greatly. What use is it to allocate
> memory to a VM if it can't use the memory because a process of another
> VM has saturated the memory bus?

Its perfectly doable on modern x86 - you use the profiling registers and
set them up so you get a threshold interrupt when too much main memory
traffic is counted (which you use to reschedule punishing the memory
user). There are research papers on it from quite a long time back but
afaik nobody ever implemented it in production although its not too hard
to do so might be an interesting project.

Alan

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

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