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.
