lkml.org 
[lkml]   [2020]   [Mar]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [futex] 8019ad13ef: will-it-scale.per_process_ops -97.8% regression
[ Just a re-send without html crud that makes all the lists unhappy.
I'm still on the road, the flight I was supposed to be on yesterday
got cancelled.. ]

I do note that the futex hashing seems to be broken by that commit. Or
at least it's questionable. It keeps hashing on "both.word", and
doesn't use the u64 field at all for hashing.

Maybe I'm mis-reading it - I didn't apply the patch, I just looked at
the patch and my source base separately.

But the 98% regression sure says something went wrong ;)

Linus

On Sun, Mar 8, 2020 at 9:22 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Sun, Mar 8, 2020, 08:02 kernel test robot <rong.a.chen@intel.com> wrote:
>>
>>
>> FYI, we noticed a -97.8% regression of will-it-scale.per_process_ops due to commit:
>>
>> commit: 8019ad13ef7f64be44d4f892af9c840179009254 ("futex: Fix inode life-time issue")
>
> Well, that's not optimal.
>
> Peter, any ideas? One of the things that worried me about changing to
> an u64 was what I think it causes extra padding, I think. And maybe
> that messes with the comparison and hashing of the futexes?

\
 
 \ /
  Last update: 2020-03-08 16:30    [W:0.080 / U:5.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site