On Thu, 3 Mar 2016, Christophe Fergeau wrote:
[...]
> > > + if (system("egrep -l '^flags\\b.*: .*\\bht\\b' /proc/cpuinfo
> > > >/dev/null 2>&1") == 0) {
> > > + /* Hyperthreading is enabled so divide by two to get the number
> > > + * of physical cores.
> > > + */
> > > + physical_core_count = physical_core_count / 2;
> > > + }
> >
> > Or as you are using /proc/cpuinfo detect from it.
> >
> > I'm not sure we should consider compatibility with other processors (like ARM).
>
> In general, I don't think we want to silently use as many cores as
> possible for cpu intensive work. This will break down as soon as 2 VMs
> trigger the streaming code at the same time, they both will be trying to
> use all the available physical cores. Even with a single VM, it could
> use 4 vcpus and do CPU intensive tasks on some of them, thus the vp8
> encoder would fight for these resources.
I can certainly separate that part of the patch.
That said it's not because we tell the encoder that it can use all the
cores that it will necessarily max them out. This will depend on the
resolution and framerate of the stream.
Also x264enc will automatically use the optimal number of threads for
its encoding needs. As soon as the resolution is high that's likely to
be 2 or 4 cores and I don't think we should artificially restrict it.
But more importantly, I think we should let the kernel worry about
scheduling.
What the video encoder should do is detect when the encoding is falling
behind and reduce the stream's fps so it can keep up rather than produce
frames that are already late. The GStreamer encoder already tweaks the
fps as a way to quickly adjust the bitrate so this mechanism can
probably be reused. This should solve both the case where the system is
too slow to encode the stream, and the case where multiple encoders or
other processes compete for CPU resources.
--
Francois Gouget <fgouget@xxxxxxxxxxxxxxx>
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/spice-devel