lkml.org 
[lkml]   [2020]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH RFC] sched: Add a per-thread core scheduling interface
    On Wed, May 20, 2020 at 3:26 PM Joel Fernandes (Google)
    <joel@joelfernandes.org> 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
    setuip?

    Linus

    \
     
     \ /
      Last update: 2020-05-21 20:39    [W:8.558 / U:0.028 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site