On 10/21/22 18:57, Mike Pattrick wrote:
On Fri, Sep 30, 2022 at 11:31 AM Adrian Moreno <[email protected]> wrote:
Currently, things like the number of handler and revalidator threads are
calculated based on the number of available CPUs. However, this number
is considered static and only calculated once, hence ignoring events
such as cpus being hotplugged, switched on/off or affinity mask
changing.
This patch makes the number of cpus be calculated every time it's
needed.
As a result of these changes (assuming the patch is backported):
- >=2.16: a change in the cpu affinity immediately reflects on
the number of threads.
- < 2.16: a change in the cpu affinity will be reflected on
the number of threads the next time there is a call to
bridge_reconfigure() (e.g: on the next DB change).
The difference in behavior is because on older versions the thread
number calculation was done on bridge reconfiguration while newer
versions moved this logic down to the dpif layer and is run on
dpif->run() stage.
Considering it has not been a huge problem up to today and that the
cpu change would be reflected sooner or later (e.g the user could
force a recalculation with a simple ovs-vsctl command), I think it
might be OK to leave like that.
Count_cpu_cores() is called many times per second in the main thread,
not just in bridge_reconfigure, but also in type_run. Would this
impact the performance of bridge_run? Or are these concerns
unjustified?
Performance concerns are never unjustified :)
I think a couple of syscalls will not add a significant delay on the main loop
that would justify a more complex solution (e.g: a timer?). What do you think?
I can benchmark it to get a ballpark idea of it's effects.
Cheers,
M
Thanks
--
Adrián Moreno
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
