Linux Core Scheduling Nears The Finish Line To Avoid Flipping Off HT

[phoronix]

Phoronix: Linux Core Scheduling Nears The Finish Line To Avoid Flipping Off HT

Besides Linux kernel developers still working to optimize code due to Retpolines overhead three years after Spectre rocked the ecosystem, another area kernel developers have still been actively working on is core scheduling for controlling the behavior of what software can share CPU resources or run on the sibling thread of a CPU core. That core scheduling work is finally closer to the mainline Linux kernel...

https://www.phoronix.com/scan.php?page=news_item&px=Core-Scheduling-Linux-Close

[microcode]

Cool, it's nice to see a cost-saving measure on a security mitigation having a human-scale positive impact on end-to-end latency in a desktop application. Usually these three are at odds with eachother.

[zboszor]

Going from previously 100% (150ms) to 33% (50ms) is 67% latency improvement, not 300%...

[skeevy420]

Going from previously 100% (150ms) to 33% (50ms) is 67% latency improvement, not 300%...

And that makes me wonder if math errors like that exist in their code too since that is a copy/paste from the LMKL.

[zasshu]

Going from previously 100% (150ms) to 33% (50ms) is 67% latency improvement, not 300%...

How? It's 3 times faster now.

[jakubo]

not sure, if it was a pun, but flipping off is not the same as switching off...

[Jumbotron]

Going from previously 100% (150ms) to 33% (50ms) is 67% latency improvement, not 300%...

Slow down. Comprehend what you are reading. Here is the text again.

" In the aforementioned patch notes it is mentioned, "ChromeOS testing shows 300% improvement in keypress latency on a Google docs key press with Google hangout test (the maximum latency drops from 150ms to 50ms for keypresses)." "

That's 300% improvement in Google Docs keypress latency.

And.....

100ms improvement (150ms down to 50ms) in Google Hangouts keypress latency.

Two different measurements. Two different apps.

[skeevy420]

Slow down. Comprehend what you are reading. Here is the text again.

" In the aforementioned patch notes it is mentioned, "ChromeOS testing shows 300% improvement in keypress latency on a Google docs key press with Google hangout test (the maximum latency drops from 150ms to 50ms for keypresses)." "

That's 300% improvement in Google Docs keypress latency.

And.....

100ms improvement (150ms down to 50ms) in Google Hangouts keypress latency.

Two different measurements. Two different apps.

from 50 to 150 is 300%; from 150 to 50 is 66.666%. Both of those were 150 and are now 50

[zboszor]

from 50 to 150 is 300%; from 150 to 50 is 66.666%. Both of those were 150 and are now 50

Even 50 to 150 (if it's some performance metrics and not latency) is just a 200% improvement, not 300%. :-) I know, lies, big lies and statistics...

[igxqrrl]

Slow down. Comprehend what you are reading. Here is the text again.

" In the aforementioned patch notes it is mentioned, "ChromeOS testing shows 300% improvement in keypress latency on a Google docs key press with Google hangout test (the maximum latency drops from 150ms to 50ms for keypresses)." "

That's 300% improvement in Google Docs keypress latency.

And.....

100ms improvement (150ms down to 50ms) in Google Hangouts keypress latency.

Two different measurements. Two different apps.

What does a 300% improvement in keypress latency mean?

Let's say that previously keypress latency was 100ms (just making up a number). A 50% improvement would make keypress latency 50ms. A 75% improvement would make keypress latency 25ms. A 99% improvement would make keypress latency 1ms. 100% improvement is impossible. that's a 0ms latency.

So what, exactly, does 300% improvement mean in this context?