Quoting Greg Freemyer <greg.freemyer@gmail.com>:
On Sun, Jan 7, 2018 at 2:22 PM, Per Jessen <per@computer.org> wrote:
Carlos E. R. wrote:
On Wednesday, 2018-01-03 at 14:05 -0500, David T-G wrote:
Carlos, et al --
...and then Carlos E. R. said... % ... % Any method to know if /my/ processor is affected? It was bought several % years ago. A list of exact processor models for looking in % /proc/cpuinfo, perhaps. [snip]
That certainly would be a nice twist. Suddenly all of those old chips out there run faster than the fancy new whiz-bangs just because they don't need the super-secure kernel shuffling :-)
Now I wonder if single core CPUs are affected.
This issue is related to paralelization optimizations. Thus I wonder whether a machine that doesn't paralelize is affected.
Jump prediction in the pipeline is not related to the number of cores.
I also wonder if a virtual machine that is given a single core of a multi-core CPU is affected.
Yes it is.
The cloud VM providers like AWS were very involved in writing the patchset. Based on their major involvement, they may be even more vulnerable than the bare metal servers.
Greg
I expect that virtual machines switch context even more often than the typical personal computer. Depending on how much of the VM runs in the kernel space, file I/O may take twice as many context switches. Many VM are running file and database heavy tasks. One benchmark of the patch performance hit used a relational database join, a common task, especially for applications like Rails that use a relational database for object-oriented data structures. And this applications are running much nearer capacity so performance hits reduce capacity and increase latency. On most personal computers, the performance reduces idle time and responsiveness (i.e., low latency). Just my .02USD, Jeffrey -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org