Re: [Xen-devel] TPR write optimization (even improves 2003 sp2)

[Keir Fraser <keir.fraser@xxxxxxxxxxxxx>]

On 07/01/2009 09:14, "James Harper" <james.harper@xxxxxxxxxxxxxxxx> wrote:

> Travis said that the testing he did showed that the value changed every
> write. The 'lazy' bit works by only writing when it actually makes a
> difference (eg don't write TPR until there is an actual interrupt
> pending I think). It's (probably much) less efficient for the case when
> a lower priority interrupt interrupts what should be a higher priority
> interrupt (but isn't, because we haven't written TPR yet), but is much
> more efficient for the most common case where it doesn't get
> interrupted. That's quite a bit more complicated than 'if new_tpr ==
> old_tpr then write else nop'...

Hmmm, you could be right. I suppose xentrace can confirm one way or the
other once you have it set up...

> I'm trying to get xentrace working to get visibility to the TPR writes
> so I can see for myself, but I don't think I am seeing what I want to
> see. Any suggestions on that? (see previous email with an incorrect
> subject of 'xentrace and MSR_READ/MSR_WRITE')

George Dunlap should be able to advise.

> How does flex priority work - does it require any work on the DomU side,
> or does it 'just work'?

It's completely transparent and just works.

> Does the VMExit caused by writing the TPR amount to the same sort of
> overhead as a hypercall? (eg replacing TPR writes with hypercalls is not
> going to make any difference is it?)

Very little. As you say, avoiding the VMEXITs entirely is the key.

 -- Keir



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