Re: [RFC] Extending numbers of event channels

[Wei Liu <Wei.Liu2@citrix.com>]

On Mon, 2012-12-03 at 18:52 +0000, David Vrabel wrote:
> On 03/12/12 16:29, Wei Liu wrote:
> > Hi all
> > 
> > There has been discussion on extending number of event channels back in
> > September [0].
> 
> It seems that the decision has been made to go for this N-level
> approach.  Were any other methods considered?
> 

Not yet. The discussion is still open.

> Would a per-VCPU ring of pending events work?  The ABI will be easier to
> extend in the future for more event channels.  The guest side code will
> be simpler.  It will be easier to fairly service the events as they will
> be processed in the order they were raised.
> 

Will there be scenario that we need to raise some evtchn's priority? The
ring approach is completely fair.

> The complexity would be in ensuring that events were not lost due to
> lack of space in the ring.  This may make the ring prohibitively large
> or require complex or expensive tracking of pending events inside Xen.
> 

This also needs to be considered and evaluated...

> > Regarding Jan's comment in [0], I don't think allowing user to specify
> > arbitrary number of levels a good idea. Because only the last level
> > should be shared among vcpus, other level should be in percpu struct to
> > allow for quicker lookup. The idea to let user specify levels will be
> > too complicated in implementation and blow up percpu section (since the
> > size grows exponentially). Three levels should be quite enough. See
> > maths below.
> > 
> > Number of event channels:
> >  * 32bit: 1024 * sizeof(unsigned long long) * BITS_PER_BYTE = 64k
> >  * 64bit: 4096 * sizeof(unsigned long long) * BITS_PER_BYTE = 512k
> > Basically the third level is a new ABI, so I choose to use unsigned long
> > long here to get more event channels.
> 
> 32-bit guests will have to treat the unsigned long long as two separate
> words and iterate over then individually.
> 
> This is easy to do -- we have an experimental build of Xen and the
> kernel that extends the number of event channels for 32-bit dom0 to 4096
> by having each selector bit select a group of 4 words.
> 

4096 is not enough. But this idea of each selector bit selecting more
words could be useful. Can you send me your patches then I will see what
I can do.


Wei.