linux-kernel - Re: [PATCH v2] sched/fair: Make PELT signal more accurate

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] [day] [month] [year] [list]

Date:   Sat, 19 Aug 2017 23:46:59 -0700
From:   Joel Fernandes <joelaf@...gle.com>
To:     Mike Galbraith <efault@....de>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@....com>,
        Brendan Jackman <brendan.jackman@....com>,
        Dietmar Eggeman <dietmar.eggemann@....com>,
        kernel-team@...roid.com, Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH v2] sched/fair: Make PELT signal more accurate

Hi Mike,

On Sat, Aug 19, 2017 at 11:00 PM, Mike Galbraith <efault@....de> wrote:
> On Sat, 2017-08-19 at 10:58 -0700, Joel Fernandes wrote:
>>
>> > Ok, I gotta ask:  In order to fix what?  What exactly does the small
>> > but existent overhead increase buy us other than an ever so slightly
>> > different chart?  What is your motivation to care about a microscopic
>> > change in signal shape?
>>
>> I wouldn't call the change "microscopic", its about 2% absolute which
>> comes down to 1% with this change (if you count in relative terms, its
>> higher and you can see the bump as the signal rises).
>> If you look at the first chart at [1] at 3.74, that's not microscopic
>> at all to me.
>
> Whether that 0.02->0.01 is viewed as significant by you or I matters
> not at all, for it to be significant, it must have measurable effect.
>
> Where is the consumer which benefits from precision improvement.. of
> the instantaneously wildly inaccurate average.  Where is the non-zero
> return on investment?  If the chart is the entire product, no sale.

One thing I want to mention is the overhead shows up only in the one
unixbench test that this is sensitive to (and even in that the
overhead is around 0.005, its within the noise for large number of
runs), for the other tests I ran like hackbench, there wasn't any
overhead at all. I am not saying that patch solves a major issue that
exists that I know off, but its just an observation while studying the
code but I'd argue its still an improvement that's harmless and
worthwhile to have.

Anyway the study is here for any one to see in the the future and it
was indeed useful to me, to learn more about the code. I am Ok with
dropping this patch if the general feeling is the inaccurate average
is Ok.

thanks for your review,

-Joel

>
>         -Mike
>
> --
> You received this message because you are subscribed to the Google Groups "kernel-team" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kernel-team+unsubscribe@...roid.com.
>