lkml.org 
[lkml]   [2022]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [mm/page_alloc] f26b3fa046: netperf.Throughput_Mbps -18.0% regression
From
On 5/10/22 21:58, ying.huang@intel.com wrote:
> On Tue, 2022-05-10 at 11:05 -0700, Linus Torvalds wrote:
>> [ Adding locking people in case they have any input ]
>>
>> On Mon, May 9, 2022 at 11:23 PM ying.huang@intel.com
>> <ying.huang@intel.com> wrote:
>>>> Can you point me to the regression report? I would like to take a look,
>>>> thanks.
>>> https://lore.kernel.org/all/1425108604.10337.84.camel@linux.intel.com/
>> +
>> Hmm.
>>
>> That explanation looks believable, except that our qspinlocks
>> shouldn't be spinning on the lock itself, but spinning on the mcs node
>> it inserts into the lock.
> The referenced regression report is very old (in Feb 2015 for 3.16-
> 3.17). The ticket spinlock was still used at that time. I believe that
> things become much better after we used qspinlock. We can test that.

Thank for the info. Qspinlock was merged into mainline since 4.2. So
ticket spinlock was used on all v3.* kernels. I was wondering why
qspinlock would have produced such a large performance regression with
just one lock spinning head waiter. So this is not such a big issue
after all.

Cheers,
Longman

\
 
 \ /
  Last update: 2022-05-11 04:07    [W:1.028 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site