[x265] CLI: new logic for '--pools <int>' option

Pradeep Ramachandran pradeep at multicorewareinc.com
Tue May 17 10:04:42 CEST 2016


On Tue, May 17, 2016 at 12:49 PM, Mateusz <mateuszb at poczta.onet.pl> wrote:

> > Using numNumaNodes * MAX_POOL_THREADS as the upper-bound on the #
> threads per numa node isn't the cleanest.
>
> My intention was to use the upper-bound for whole threads number (on all
> NUMAs).
>
> This patch is only for case '--pools N' where N is a number, for example
> '--pools 55' create exactly 55 threads (with affinity for all logical CPUs
> on all NUMAs). Old logic for '--pools 55' was to create min(55, #CPU on
> NUMA 0) threads on NUMA 0 and 0 threads on all remaining NUMAs. To use old
> logic with this patch you can add comma: '--pools 55,'
>

In a machine with N nodes, the logical thing to do is to specify N values
to the --pools option. The effect above that you describe when only one
value is specified is just coincidence and certainly not intentional.
Enabling support with '--pools 55,' for example, isn't really essential.


> If I use '--pools 6144 -F16' option with this patch on i5 CPU, I get
> x265 [info]: Thread pool created using 64 threads
> x265 [info]: frame threads / pool features       : 16 / wpp(12 rows)
>
> Without this patch I get only 4 threads.


This is the problem that I feared - since the HW has only 4 threads, even
though you specified 6144 as the # SW threads you wanted to create, we
should've spawned only 4 SW threads also. Using min CPUs across all NUMA
nodes will ensure that you only spawn 4 SW threads. You are currently
clipped at 64 threads because that is the max # threads in on pool (limited
by the fact that we use a 64-bit bit vector for a mask and hence can only
track 64 threads per pool).

> Also, can you please include the patch as inline in future so that it
> becomes easier to review?
>
> I will do that, thanks for info. My first attempt to do this fail due to
> line breaking in my e-mail client.
>
>
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20160517/6e8e2860/attachment.html>


More information about the x265-devel mailing list