linux-kernel - Re: [PATCH 1/4] sched: make nr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87wns14gvx.ffs@nanos.tec.linutronix.de>
Date:   Fri, 14 May 2021 14:52:18 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Alexey Dobriyan <adobriyan@...il.com>, mingo@...hat.com,
        Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org,
        x86@...nel.org, Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH 1/4] sched: make nr_running() return 32-bit

Ingo,

On Thu, May 13 2021 at 11:58, Ingo Molnar wrote:
> * Thomas Gleixner <tglx@...utronix.de> wrote:
>
> You often won't see these effects in the 'size vmlinux' output, because 
> function alignment padding reserves usually hide 1-2 byte size improvements 
> in generated code.

I'm not that stupid. And I certainly looked where this comes from.

> More importantly, the maintenance benchmark in these cases is not whether a 
> change actively helps every architecture we care about - but whether the 
> change is a *disadvantage* for them - and it isn't here.

That's clearly documented in the changelogs of these patches, right?

> Changes that primarily benefit one common architecture, while not others, 
> are still eligible for upstream merging if they otherwise meet the quality 
> threshold and don't hurt the other architectures.

That has been proven by compile testing the relevant architectures as
documented in the changelog, right?

> TL;DR:
>
> This benefits from this series are small, but are far from 'useless churn', 
> unless we want to arbitrarily cut off technically valid contributions that 
> improve generated code, data structure size and code readability, submitted 
> by a long-time contributor who has contributed over 1,300 patches to the 
> kernel already, just because we don't think these add up a significant 
> enough benefit?
>
> No doubt the quality barrier must be and is higher for smaller changes - 
> but this series IMO passed that barrier.
>
> Anyway, I've Cc:-ed Linus and Greg, if you are advocating for some sort of 
> cut-off threshold for small but measurable improvements from long-time 
> contributors, it should probably be clearly specified & documented in 
> Documentation/SubmittingPatches ...

What I'm arguing about is already documented:

  Quantify optimizations and trade-offs.  If you claim improvements in
  performance, memory consumption, stack footprint, or binary size,
  include numbers that back them up.

That series fails to provide any of this and it does not matter whether
this comes from a long time contributor or from a newbie.

Long term contributors are not excempt from documented process. In fact
they should lead by example.

If you as a maintainer put different measures on newbies and long-time
contrinbutors then you pretty much have proven the point the UMN people
tried to make (in the wrong way).

Thanks,

        tglx