Re: Identification of HTT cores on newer (CPUID leaf 11) Intel processors
On Wednesday, September 14, 2011 4:02:41 pm Andrew Boyer wrote: On Sep 14, 2011, at 3:56 PM, Andriy Gapon wrote: on 14/09/2011 20:59 Andrew Boyer said the following: When FreeBSD examines the CPU topology using CPUID leaf 11 in topo_probe_0xb(), it never sets hyperthreading_cpus. At the end of topo_probe_0x4() it sets hyperthreading_cpus = cpu_logical. Adding that assignment to line 316 of sys/amd64/amd64/mp_machdep.c seems to do the right thing on a system with two quad-core E5620 CPUs. The APIC IDs that appear when SMT is enabled in the BIOS get marked AP/HT. Do you agree? I agree, but... But see this: http://thread.gmane.org/gmane.os.freebsd.devel.hackers/44007/focus=44024 Someone long ago has decided that new HTT is not the same as old HTT and that some rules that apply to old HTT should not apply to new HTT. Even the name. I think that that's not correct. But it doesn't seem that I am able to engage into a discussion the person who made that decision. Also I can not find any other interested developer either. Anyway, hyperthreading_cpus variable is useless beyond dmesg cosmetics. And I don't think that any of my changes affected the dmesg output. In my avgBSD I have different SMP topology code, but it's not ready yet to be submitted for merge into the main tree. -- Andriy Gapon Actually, it's not useless. If you don't set it to something other than zero the machdep.hyperthreading_allowed tunable doesn't do anything, since it can't tell which CPUs are actually HTT. The reason the machdep.hyperthreading_allowed tunable was added was to disable HTT on Pentium4's due to a security issue Colin found that was specific to the HTT on Pentium4's. The second generation HTT is not (AFAIK) subject to the same vulnerability. Thus, people disabling HTT because they are paranoid about RSA keys being sniffed shouldn't end up disabling HTT on newer CPUs unnecessarily. In my opinion, though, the old HTT stuff is water way under the bridge at this point (and I'm a bit skeptical about the practical vulnerability of the old HTT stuff anyway). I think the right way for an admin to disable HTT is to disable it in the BIOS so that it doesn't show up in the MADT. Back when we were doing the MPTABLE_FORCE_HTT hack having a separate tunable made sense (and it possibly made some limited sense if you were worried about the vulnerability on running machines). However, at this point I think the tunable should just go away and admins should configure HTT on or off in the BIOS like they would for any other OS. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Identification of HTT cores on newer (CPUID leaf 11) Intel processors
On Sep 16, 2011, at 8:07 AM, John Baldwin wrote: I think the right way for an admin to disable HTT is to disable it in the BIOS so that it doesn't show up in the MADT. Back when we were doing the MPTABLE_FORCE_HTT hack having a separate tunable made sense (and it possibly made some limited sense if you were worried about the vulnerability on running machines). However, at this point I think the tunable should just go away and admins should configure HTT on or off in the BIOS like they would for any other OS. -- John Baldwin To do it this way (leave SMT enabled in the BIOS but disabled in the OS) makes it easier to release a future upgrade to take advantage of those cores. Once systems are distributed to customer sites it becomes very difficult to do BIOS maintenance. -Andrew -- Andrew Boyerabo...@averesystems.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Identification of HTT cores on newer (CPUID leaf 11) Intel processors
on 14/09/2011 20:59 Andrew Boyer said the following: When FreeBSD examines the CPU topology using CPUID leaf 11 in topo_probe_0xb(), it never sets hyperthreading_cpus. At the end of topo_probe_0x4() it sets hyperthreading_cpus = cpu_logical. Adding that assignment to line 316 of sys/amd64/amd64/mp_machdep.c seems to do the right thing on a system with two quad-core E5620 CPUs. The APIC IDs that appear when SMT is enabled in the BIOS get marked AP/HT. Do you agree? I agree, but... But see this: http://thread.gmane.org/gmane.os.freebsd.devel.hackers/44007/focus=44024 Someone long ago has decided that new HTT is not the same as old HTT and that some rules that apply to old HTT should not apply to new HTT. Even the name. I think that that's not correct. But it doesn't seem that I am able to engage into a discussion the person who made that decision. Also I can not find any other interested developer either. Anyway, hyperthreading_cpus variable is useless beyond dmesg cosmetics. And I don't think that any of my changes affected the dmesg output. In my avgBSD I have different SMP topology code, but it's not ready yet to be submitted for merge into the main tree. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Identification of HTT cores on newer (CPUID leaf 11) Intel processors
On Sep 14, 2011, at 3:56 PM, Andriy Gapon wrote: on 14/09/2011 20:59 Andrew Boyer said the following: When FreeBSD examines the CPU topology using CPUID leaf 11 in topo_probe_0xb(), it never sets hyperthreading_cpus. At the end of topo_probe_0x4() it sets hyperthreading_cpus = cpu_logical. Adding that assignment to line 316 of sys/amd64/amd64/mp_machdep.c seems to do the right thing on a system with two quad-core E5620 CPUs. The APIC IDs that appear when SMT is enabled in the BIOS get marked AP/HT. Do you agree? I agree, but... But see this: http://thread.gmane.org/gmane.os.freebsd.devel.hackers/44007/focus=44024 Someone long ago has decided that new HTT is not the same as old HTT and that some rules that apply to old HTT should not apply to new HTT. Even the name. I think that that's not correct. But it doesn't seem that I am able to engage into a discussion the person who made that decision. Also I can not find any other interested developer either. Anyway, hyperthreading_cpus variable is useless beyond dmesg cosmetics. And I don't think that any of my changes affected the dmesg output. In my avgBSD I have different SMP topology code, but it's not ready yet to be submitted for merge into the main tree. -- Andriy Gapon Actually, it's not useless. If you don't set it to something other than zero the machdep.hyperthreading_allowed tunable doesn't do anything, since it can't tell which CPUs are actually HTT. -Andrew -- Andrew Boyerabo...@averesystems.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Identification of HTT cores on newer (CPUID leaf 11) Intel processors
on 14/09/2011 23:02 Andrew Boyer said the following: Actually, it's not useless. If you don't set it to something other than zero the machdep.hyperthreading_allowed tunable doesn't do anything, since it can't tell which CPUs are actually HTT. Ah, you are right. That works correctly with my (not yet published) patch that doesn't make distinction between HTT flavors. But in the main tree SMT != HTT. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
