lkml.org 
[lkml]   [2019]   [Feb]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/5] x86/percpu: Differentiate this_cpu_{}() and __this_cpu_{}()
Date
> On Feb 27, 2019, at 8:14 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> On Wed, Feb 27, 2019 at 2:16 AM Peter Zijlstra <peterz@infradead.org> wrote:
>> Nadav Amit reported that commit:
>>
>> b59167ac7baf ("x86/percpu: Fix this_cpu_read()")
>>
>> added a bunch of constraints to all sorts of code; and while some of
>> that was correct and desired, some of that seems superfluous.
>
> Trivial (but entirely untested) patch attached.
>
> That said, I didn't actually check how it affects code generation.
> Nadav, would you check the code sequences you originally noticed?

The original issue was raised while I was looking into a dropped patch of
Matthew Wilcox that caused code size increase [1]. As a result I noticed
that Peter’s patch caused big changes to the generated assembly across the
kernel - I did not have a specific scenario that I cared about.

The patch you sent (“+m/-volatile”) does increase the code size by 1728
bytes. Although code size is not the only metric for “code optimization”,
the original patch of Peter (“volatile”) only increased the code size by 201
bytes. Peter’s original change also affected only 72 functions vs 228 that
impacted by the new patch.

I’ll have a look at some specific function assembly, but overall, the “+m”
approach might prevent even more code optimizations than the “volatile” one.

I’ll send an example or two later.

Regards,
Nadav


[1] https://marc.info/?l=linux-mm&m=154341370216693&w=2

\
 
 \ /
  Last update: 2019-02-27 18:58    [W:0.091 / U:26.940 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site