Hi Will,
On 2017-08-25 12:48, Vikram Mulukutla wrote:
Hi Will,
On 2017-08-15 11:40, Will Deacon wrote:
Hi Vikram,
On Thu, Aug 03, 2017 at 04:25:12PM -0700, Vikram Mulukutla wrote:
On 2017-07-31 06:13, Will Deacon wrote:
>On Fri, Jul 28, 2017 at 12:09:38PM -0700, Vikram Mulukutla wrote:
>>On 2017-07-28 02:28, Will Deacon wrote:
>>>On Thu, Jul 27, 2017 at 06:10:34PM -0700, Vikram Mulukutla wrote:
>>>
>>This does seem to help. Here's some data after 5 runs with and without
>>the
>>patch.
>
>Blimey, that does seem to make a difference. Shame it's so ugly! Would you
>be able to experiment with other values for CPU_RELAX_WFE_THRESHOLD? I had
>it set to 10000 in the diff I posted, but that might be higher than
>optimal.
>It would be interested to see if it correlates with num_possible_cpus()
>for the highly contended case.
>
>Will
Sorry for the late response - I should hopefully have some more data with
different thresholds before the week is finished or on Monday.
Did you get anywhere with the threshold heuristic?
Will
Here's some data from experiments that I finally got to today. I decided
to recompile for every value of the threshold. Was doing a binary search
of sorts and then started reducing by orders of magnitude. There pairs
of rows here:
Well here's something interesting. I tried a different platform and found that
the workaround doesn't help much at all, similar to Qiao's observation on his b.L
chipset. Something to do with the WFE implementation or event-stream?