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  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]
Date:   Thu, 21 May 2020 11:31:38 -0700
From:   Linus Torvalds <>
To:     "Joel Fernandes (Google)" <>
Cc:     Nishanth Aravamudan <>,
        Julien Desfossez <>,
        Peter Zijlstra <>,
        Tim Chen <>,
        Ingo Molnar <>,
        Thomas Gleixner <>,
        Paul Turner <>,
        vpillai <>,
        Linux Kernel Mailing List <>,
        Frédéric Weisbecker <>,
        Kees Cook <>,
        Greg Kerr <>, Phil Auld <>,
        Aaron Lu <>,
        Aubrey Li <>,,
        Valentin Schneider <>,
        Mel Gorman <>,
        Pawan Gupta <>,
        Paolo Bonzini <>,
        Joel Fernandes <>
Subject: Re: [PATCH RFC] sched: Add a per-thread core scheduling interface

On Wed, May 20, 2020 at 3:26 PM Joel Fernandes (Google)
<> wrote:
> ChromeOS will use core-scheduling to securely enable hyperthreading.
> This cuts down the keypress latency in Google docs from 150ms to 50ms
> while improving the camera streaming frame rate by ~3%.

I'm assuming this is "compared to SMT disabled"?

What is the cost compared to "SMT enabled but no core scheduling"?

But the real reason I'm piping up is that your  latency benchmark
sounds very cool.

Generally throughput benchmarks are much easier to do, how do you do
this latency benchmark, and is it perhaps something that could be run
more widely (ie I'm thinking that if it's generic enough and stable
enough to be run by some of the performance regression checking
robots, it would be a much more interesting test-case than some of the
ones they run right now...)

I'm looking at that "threaded phoronix gzip performance regression"
thread due to a totally unrelated scheduling change ("sched/fair:
Rework load_balance()"), and then I see this thread and my reaction is
"the keypress latency thing sounds like a much more interesting
performance test than threaded gzip from clear linux".

But the threaded gzip test is presumably trivial to script, while your
latency test is perhaps very specific to one particular platform and


Powered by blists - more mailing lists