On 26/11/15 18:49, Andrew Cooper wrote: > On 26/11/15 16:14, David Vrabel wrote: >> If more than 1024 event channels are bound to a evtchn device then it >> possible (even with well behaved applications) for the ring to >> overflow and events to be lost (reported as an -EFBIG error). >> >> Dynamically increase the size of the ring so there is always enough >> space for all bound events. Well behaved applicables that only unmask >> events after draining them from the ring can thus no longer lose >> events. >> >> However, an application could unmask an event before draining it, >> allowing multiple entries per port to accumulate in the ring, and a >> overflow could still occur. So the overflow detection and reporting >> is retained. >> >> The ring size is initially only 64 entries so the common use case of >> an application only binding a few events will use less memory than >> before. The ring size may grow to 512 KiB (enough for all 2^17 >> possible channels). This order 7 kmalloc() may fail due to memory >> fragmentation, so we fall back to trying vmalloc(). >> >> Signed-off-by: David Vrabel <david.vra...@citrix.com> > > Reviewed-by: Andrew Cooper <andrew.coop...@citrix.com>
Applied to for-linus-4.4, thanks. David _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
