> Uuh, not that I'm aware of that in .10 the PTI stuff was implemented. > In that .10-system, "cat /proc/cpuinfo" shows nothing in the "bugs:" > line (while .12 says "bugs: cpu_insecure") and there is nothing about > KPTI in dmesg when booting the .10.
I've just upgraded my LFS-7.10 system to 4.9.75 and dmesg shows: ... [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1 [ 0.000000] Kernel/User page tables isolation: enabled [ 0.000000] Hierarchical RCU implementation. ... I made sure to look for it! ;-) > > I have no idea about the changes with each generation, but for > recent models, provided hyperthreading is enabled, linux sees 8 > cores in this situation - depending on the kernel config, it might > slightly change how things are scheduled, but overall it rotates > jobs between all cores. True, there is scheduling being done at the OS level, and the hyperthreading chips are telling the OS, "Give me two threads to do, I can handle it." But there is also a scheduling process going on *within* the processor as the two threads vie for processing elements within the pipeline. There are differences between different architectures, but the best evidence for competitive bottlenecks within a hyperthreaded CPU is that Intel only claimed a 30% performance improvement (I believe on the single core P4D). My dual core Conroes will give much more because each pipeline is separate, without contention, and the cores only compete for L2 cache and the off-chip Bus Interface. > The difference with hyperthreading is that things like > floating-point get shared between siblings. More than that! See this for the Nehalem internals: https://upload.wikimedia.org/wikipedia/commons/6/64/Intel_Nehalem_arch.svg > If I watch 'top' (recent version) I can see an activity line for > each core. And the activity moves around. Indeed, but that's at the OS dispatching level. If you could get fine enough granularity, again depending on specific CPU architecture, you'd see that the "raw" performance of those "cores" either 1) split into two groups, or 2) change depending on whether there is one or two threads running in the core. > I asked on lwn, so far the consensus is that a lot of 32-bit x86 is > embedded and never gets updated anyway. Distros are gradually > dropping i686, AFAICS nobody has offered a potential fix - but there > is a PoC exploit at github which can apparently run on i686. Yeah, kernel devs always get the latest and greatest HW, so it's not their ox getting gored. It's so easy for them to presume nothing else matters. If you're on LKML, please tell them their assumption is wrong! The 32-bit systems are still vulnerable, still doing important jobs, and if updating the software is going to be difficult, replacing the hardware in a timely fashion is very much more so. What kind of important jobs? How about all the infrastructure we all depend upon? Like having potable water coming out of the tap? > said he *thought* the problem started with the Westmere generation. So the guys who found it and said it affected everything since PPro were wrong? Maybe he should tell them. -- Paul Rogers [email protected] Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
