Re: xenstore - Suggestion of batching watch events

[Andriy Sultanov <sultanovandriy@xxxxxxxxx>]

On 6/24/25 4:06 PM, Jürgen Groß wrote:

> The main reason for the large number of watch events after a 
> transaction is
> the fact that the watch for e.g. detecting the addition of a new block 
> device
> will be set on a node being common for all potential block devices 
> handled
> by the watcher. This results in a watch event for each single node 
> modified
> below this node, which are usually quite a lot even when only adding a 
> single
> device.
>
> The solution for this problem is NOT to batch all the events and to 
> ignore the
> majority of those events, but to avoid creating most of those events.
>
> For this reason the Xenstore protocol has been extended to allow for 
> limiting
> the number of node levels below a watched node to be relevant for a 
> watch to
> fire.
>
> What is missing so far are Xenstore implementations to support this 
> feature,
> and Xenstore users to make use of it. I'm working on supporting this in
> C xenstored, but due to other urgent work this will probably land 
> upstream only
> in the Xen 4.22 time frame, probably together with Xen tools (libxl) 
> making use
> of this feature.
>
>
> Juergen
I was not aware that watch has had a (relatively) new unimplemented 
parameter
added, thanks! I've noted this on the oxenstored side.
(https://github.com/xapi-project/oxenstored/issues/15)

But I think this only covers part of the problem. Looking at the 
concrete case of
xenopsd and Windows VMs, xenopsd cares about most of the nodes it receives
watch events from, the issue is that it doesn't know when these are grouped
together in one way or another.