On Wed, May 20, 2020 at 3:26 PM Joel Fernandes (Google) <j...@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