<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 10, 2017 at 12:32 PM, Michael Lackner <span dir="ltr"><<a href="mailto:michael.lackner@unileoben.ac.at" target="_blank">michael.lackner@unileoben.ac.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On 05/10/2017 08:24 AM, Pradeep Ramachandran wrote:<br>
> On Wed, May 10, 2017 at 11:12 AM, Michael Lackner <<br>
> <a href="mailto:michael.lackner@unileoben.ac.at">michael.lackner@unileoben.ac.<wbr>at</a>> wrote:<br>
><br>
>> Thank you very much for your input!<br>
>><br>
>> Since --pmode and --pme seem to break NUMA support, I disabled them. I<br>
>> simply cannot tell<br>
>> users that they have to switch off NUMA in their UEFI firmware just for<br>
>> this one<br>
>> application. There may be a lot of situations where this is just not<br>
>> doable.<br>
>><br>
>> If there is a way to make --pmode --pme work together with x265s' NUMA<br>
>> support, I'd use<br>
>> it, but I don't know how?<br>
><br>
> Could you please elaborate more here? It seems to work ok for us here. I've<br>
> tried on CentOS and Win Server 2017 dual socket systems and I see all<br>
> sockets being used.<br>
<br>
</span>It's like this: x265 does *say* it's using 32 threads in two NUMA pools. That's just how<br>
it should be. But it behaves very weirdly, almost never loading more than two logical<br>
cores. FPS are extremely low, so it's really slow.<br>
<br>
CPU load stays at 190-200%, sometimes briefly dropping to 140-150%, where it should be in<br>
the range of 2800-3200%. As soon as I remove --pmode --pme, the system is being loaded<br>
very well! It almost never drops below the 3000% (30 cores) mark then.<br>
<br>
I also works *with* --pmode --pme, but only if NUMA is disabled on the firmware level,<br>
showing only a classic, flat topology to the OS.<br>
<br>
That behavior can be seen on CentOS 7.3 Linux, having compiled x265 2.4+2 with GCC 4.8.5<br>
and yasm 1.3.0. The machine is a HP ProLiant DL360 Gen9 machine with two Intel Xeon<br>
E5-2620 CPUs.<br>
<br>
Removing --pmode --pme was suggested by Mario *LigH* Rohkrämer earlier in this thread.<br></blockquote><div><br></div><div>This seems something specific with your configuration setup. I just tried an identical experiment on two systems that I have which are dual-socket E5-2699 v4s (88 threads spread across two sockets) running CentOS 6.8 and CentOS 7.2. I compiled x265 with gcc version 4.4 and am able to see utilization actually pick up closer to 5000% (monitored using htop) when --pme and --pmode are enabled in the command line; without these options, the utilization is closer to 3300%.  </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Here is my topology when NUMA is enabled (pretty simple):<br>
<br>
# numactl -H<br>
available: 2 nodes (0-1)<br>
node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23<br>
node 0 size: 32638 MB<br>
node 0 free: 266 MB<br>
node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31<br>
node 1 size: 32768 MB<br>
node 1 free: 82 MB<br>
node distances:<br>
node   0   1<br>
  0:  10  21<br>
  1:  21  10<br>
<br>
Thanks!<br></blockquote><div><br></div><div>You seem to have very little free memory in each node which might be making you go to disk and therefore affecting performance. I recommend trying to free some memory up before running x265 to see if that helps.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div class="gmail-h5"><br>
>> Ah yes, I've also found that 8K does indeed help a ton. With 4K and<br>
>> similar settings, I'm<br>
>> able to load 16-25 CPUs currently, sometimes briefly 30. With 8K, load is<br>
>> much higher.<br>
>><br>
>> Maybe you can advise how to maximize parallelization / loading as many<br>
>> CPUs as possible<br>
>> without breaking NUMA support on both Windows and Linux.<br>
>><br>
>> I'm saying this, because my benchmarking project is targeting multiple<br>
>> operating systems,<br>
>> it currently works on:<br>
>>   * Windows NT 5.2 & 6.0 (wo. NUMA)<br>
>>   * Windows NT 6.1 - 10.0 (w. NUMA)<br>
>>   * MacOS X (wo. NUMA)<br>
>>   * Linux (w. and wo. NUMA)<br>
>>   * FreeBSD, OpenBSD, NetBSD and DragonFly BSD UNIX (wo. NUMA)<br>
>>   * Solaris (wo. NUMA)<br>
>>   * Haiku OS (wo. NUMA)<br>
>><br>
>> Thank you very much!<br>
>><br>
>> Best,<br>
>> Michael<br>
>><br>
>> On 05/10/2017 07:21 AM, Pradeep Ramachandran wrote:<br>
>>> Michael,<br>
>>> Adding --lookahead-threads 2 statically allocated two threads for<br>
>>> lookahead. Therefore, the worker threads launched to work on WPP will<br>
>> 32-2<br>
>>> = 30 in count. We've found some situations in which statically allocating<br>
>>> threads for lookahead was useful and therefore decided to expose it to<br>
>> the<br>
>>> user. Please see if this helps your use-case and enable appropriately.<br>
>>><br>
>>> Now as far as scaling up for 8K goes, a single instance of x265 scales up<br>
>>> well to 25-30 threads depending on the preset you're running in. We've<br>
>>> found pmode and pme help performance considerably on some Broadwell<br>
>> server<br>
>>> systems but again, that is also dependent on content. I would encourage<br>
>> you<br>
>>> play with those settings and see if they help your use case. Beyond these<br>
>>> thread counts, one instance of x265 may not be beneficial for you.<br>
>>><br>
>>> Pradeep.<br>
>>><br>
>>> On Fri, May 5, 2017 at 3:26 PM, Michael Lackner <<br>
>>> <a href="mailto:michael.lackner@unileoben.ac.at">michael.lackner@unileoben.ac.<wbr>at</a>> wrote:<br>
>>><br>
>>>> I found the reason for "why did x265 use 30 threads and not 32, when I<br>
>>>> have 32 CPUs".<br>
>>>><br>
>>>> Actually, it was (once again) my own fault. Thinking I know better than<br>
>>>> x265, I spawned<br>
>>>> two lookahead threads starting with 32 logical CPUs<br>
>> ('--lookahead-threads<br>
>>>> 2').<br>
>>>><br>
>>>> It seems what x265 does is to reserve two dedicated CPUs for this, but<br>
>>>> then it couldn't<br>
>>>> permanently saturate them.<br>
>>>><br>
>>>> I still don't know when I should be starting with that stuff for 8K<br>
>>>> content. 64 CPUs? 256<br>
>>>> CPUs? Or should I leave everything to x265? My goal was to be able to<br>
>>>> fully load as many<br>
>>>> CPUs as possible in the future.<br>
>>>><br>
>>>> In any case, the culprit was myself.<br>
>>>><br>
>>>> On 05/04/2017 11:18 AM, Mario *LigH* Rohkrämer wrote:<br>
>>>>> Am 04.05.2017, 10:58 Uhr, schrieb Michael Lackner <<br>
>>>> <a href="mailto:michael.lackner@unileoben.ac.at">michael.lackner@unileoben.ac.<wbr>at</a>>:<br>
>>>>><br>
>>>>>> Still wondering why not 32, but ok.<br>
>>>>><br>
>>>>> x265 will calculate how many threads it will really need to utilize the<br>
>>>> WPP and other<br>
>>>>> parallelizable steps, in relation to the frame dimensions and the<br>
>>>> complexity. It may not<br>
>>>>> *need* more than 30 threads, would not have any task to give to two<br>
>>>> more. Possibly.<br>
>>>>> Developers know better...<br>
>>>><br>
>>>> --<br>
>>>> Michael Lackner<br>
>>>> Lehrstuhl für Informationstechnologie (CiT)<br>
>>>> Montanuniversität Leoben<br>
>>>> Tel.: +43 (0)3842/402-1505 | Mail: <a href="mailto:michael.lackner@unileoben.ac.at">michael.lackner@unileoben.ac.<wbr>at</a><br>
>>>> Fax.: +43 (0)3842/402-1502 | Web: <a href="http://institute.unileoben.ac" rel="noreferrer" target="_blank">http://institute.unileoben.ac</a>.<br>
>>>> at/infotech<br>
>>>> ______________________________<wbr>_________________<br>
>>>> x265-devel mailing list<br>
>>>> <a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
>>>> <a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/<wbr>listinfo/x265-devel</a><br>
>><br>
>> --<br>
>> Michael Lackner<br>
>> Lehrstuhl für Informationstechnologie (CiT)<br>
>> Montanuniversität Leoben<br>
>> Tel.: +43 (0)3842/402-1505 | Mail: <a href="mailto:michael.lackner@unileoben.ac.at">michael.lackner@unileoben.ac.<wbr>at</a><br>
>> Fax.: +43 (0)3842/402-1502 | Web: <a href="http://institute.unileoben.ac" rel="noreferrer" target="_blank">http://institute.unileoben.ac</a>.<br>
>> at/infotech<br>
>> ______________________________<wbr>_________________<br>
>> x265-devel mailing list<br>
>> <a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
>> <a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/<wbr>listinfo/x265-devel</a><br>
>><br>
>><br>
>><br>
</div></div>>> N �n�r����)em�h�yhiם�w^��<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
--<br>
Michael Lackner<br>
Lehrstuhl für Informationstechnologie (CiT)<br>
Montanuniversität Leoben<br>
Tel.: +43 (0)3842/402-1505 | Mail: <a href="mailto:michael.lackner@unileoben.ac.at">michael.lackner@unileoben.ac.<wbr>at</a><br>
Fax.: +43 (0)3842/402-1502 | Web: <a href="http://institute.unileoben.ac.at/infotech" rel="noreferrer" target="_blank">http://institute.unileoben.ac.<wbr>at/infotech</a><br>
______________________________<wbr>_________________<br>
x265-devel mailing list<br>
<a href="mailto:x265-devel@videolan.org">x265-devel@videolan.org</a><br>
<a href="https://mailman.videolan.org/listinfo/x265-devel" rel="noreferrer" target="_blank">https://mailman.videolan.org/<wbr>listinfo/x265-devel</a><br>
</div></div></blockquote></div><br></div></div>