| View previous topic :: View next topic |
| Author |
Message |
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
 Posted: Fri Aug 21, 2020 7:42 pm Post subject: Disabling CONFIG_USB_PCI affects L1/L2 and RAM performance |
 |
|
So I'm taking the long way around to do things. I have my new server mostly built, Sexy Prime (Google it), i5-8500T, Z390, 64 GB DDR4 @ 4000 MHz with tightened timings, and my general curiosity wants to benchmark it against my old server, Atlas, a Q9400S, P965, 8 GB DDR2 @ 1000 MHz 4-4-4-10. Night and day between them. The titled problem is with Atlas while I see how well I can "build" a Gentoo environment on an SSD to test a variety of performance metrics between the two.
While I was trimming crap out of the kernel, I forgot that I need CONFIG_USB_PCI for CONFIG_USB_UHCI_HCD on P965 in order to actually have USB function. Okay, big whoop, I have SSH as my primary access/control method. Well, just before that kernel build, I had run a small batch of memory benchmarks with sysbench and Memory Latency. Both output different numbers for the same array size, but they both showed ~25-30% performance regression on L1 cache, L2 cache, and system memory. I take note and time my kernel compile which ballooned from 22 minutes to 30 minutes. Since I had time to think during the compilation, I recalled Wendel from Level1Tech/Level1Linux fame and a conversation where he mentioned that compilation of code is largely a cache speed test.
After some grueling time later, because I've generally avoided running initramfs but now I'm playing with booting root on a btrfs snapshot, I confirm by flipping that config option back on an off, that it alone was responsible for the performance regression. But WHY!?!?! It's the PCI bus, and USB. Which are dependent upon the FSB & CPU, not the other way around. The architectural hierarchy is either not well understood by your truly, or this is a platform bug.. I'm still iteratively removing drivers and turning off ambiguously named kernel features in 5.4.48 so I don't have a solid .config to provide as a sample. I consider myself a hardware guy more than software, but this is just a baffling happenstance I'd like to understand.
I run netdata for system monitoring since I've started the software loadout on Sexy Prime. It runs very well on Atlas too and I'm happy to see that it's being maintained in the Gentoo repository. It helped me note a TLB performance problem that kernel change logs possibly indicate a resolve TLB regression. From looking at it's logs, I can assure you that nothing spurious or consistent showed up during the kernel compilation so the cache and system memory performance regression caused the observed CPU computation regression.
Can anyone shed some light on what happened here?
In the meantime, the live kernel from the minimal instal image has ~15% greater L1/L2 throughput numbers than the initial kernel I booted too and I copied the /proc/config.gz too  . If I'm missing 15% CPU performance for similar reasons because of something else I turned off, I want to understand what and why so I'm going to go hunt that down... |
|
| Back to top |
|
 |
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Sat Aug 22, 2020 6:35 am Post subject: |
|
|
| How do the numbers look with Intel hardware bug mitigations turned off? |
|
| Back to top |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Sat Aug 22, 2020 9:21 am Post subject: |
|
|
My current kernel:
| Code: | [ 0.000000] microcode: microcode updated early to revision 0xa0e, date = 2015-07-29
...
[ 0.258076] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[ 0.258080] Spectre V2 : Spectre mitigation: kernel not compiled with retpoline; no mitigation available!
[ 0.258081] Speculative Store Bypass: Vulnerable
[ 0.258087] MDS: Vulnerable: Clear CPU buffers attempted, no microcode |
"LiveCD" kernel:
| Code: | [ 0.268364] Spectre V1 : Mitigation: usercopy/swapgs barriers and __user pointer sanitization
[ 0.268368] Spectre V2 : Mitigation: Full generic retpoline
[ 0.268370] Spectre V2 : Spectre v2 / SpectreRSB mitigation: Filling RSB on context switch
[ 0.268372] Speculative Store Bypass: Vulnerable
[ 0.268375] MDS: Vulnerable: Clear CPU buffers attempted, no microcode |
Emerge --info:
| Code: | app-shells/bash: 5.0_p18::gentoo
dev-java/java-config: 2.3.1::gentoo
dev-lang/perl: 5.30.3-r1::gentoo
dev-lang/python: 2.7.18-r1::gentoo, 3.7.9::gentoo, 3.8.5::gentoo, 3.9.0_rc1::gentoo
dev-util/ccache: 3.7.11::gentoo
dev-util/cmake: 3.18.1::gentoo
sys-apps/baselayout: 2.7::gentoo
sys-apps/openrc: 0.42.1::gentoo
sys-apps/sandbox: 2.20::gentoo
sys-devel/autoconf: 2.13-r1::gentoo, 2.69-r5::gentoo
sys-devel/automake: 1.11.6-r3::gentoo, 1.16.2::gentoo
sys-devel/binutils: 2.34-r2::gentoo
sys-devel/gcc: 10.2.0::gentoo
sys-devel/gcc-config: 2.3.1::gentoo
sys-devel/libtool: 2.4.6-r6::gentoo
sys-devel/make: 4.3::gentoo
sys-kernel/linux-headers: 5.8::gentoo (virtual/os-headers)
sys-libs/glibc: 2.32::gentoo |
About a 1% difference from having all but MDS fixed, which, iirc, cannot be mitigated. Microcode load in at boot seems to be the primary difference between the two before I started tweaking things.
I dropped off Gentoo/Linux a few years prior to Spectre/Meltdown so I'm still a bit iffy on how to fully disable them. I'm going to rebuild my initramfs without the microcode and see what happens; bbl. |
|
| Back to top |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Sat Aug 22, 2020 9:35 am Post subject: |
|
|
memory latency results prior to microcode removal: | Code: | --------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations UserCounters...
--------------------------------------------------------------------------------------------
memory_latency_list/size KB:1 0.939 ns 1.01 ns 692000000 Nodes=16 Read Rate=59.1357G/s
memory_latency_list/size KB:2 1.56 ns 1.69 ns 417000000 Nodes=32 Read Rate=35.2429G/s
memory_latency_list/size KB:4 1.56 ns 1.68 ns 416000000 Nodes=64 Read Rate=35.4965G/s
memory_latency_list/size KB:8 1.56 ns 1.69 ns 417000000 Nodes=128 Read Rate=35.2695G/s
memory_latency_list/size KB:16 1.57 ns 1.68 ns 416000000 Nodes=256 Read Rate=35.4801G/s
memory_latency_list/size KB:32 8.03 ns 8.67 ns 82000000 Nodes=512 Read Rate=6.87213G/s
memory_latency_list/size KB:64 8.14 ns 8.73 ns 79000000 Nodes=1024 Read Rate=6.82437G/s
memory_latency_list/size KB:128 8.12 ns 8.72 ns 81000000 Nodes=2k Read Rate=6.83389G/s
memory_latency_list/size KB:256 8.14 ns 8.77 ns 80000000 Nodes=4k Read Rate=6.79887G/s
memory_latency_list/size KB:1024 10.4 ns 11.2 ns 78000000 Nodes=16k Read Rate=5.31436G/s
memory_latency_list/size KB:2048 61.2 ns 65.8 ns 9000000 Nodes=32k Read Rate=928.255M/s
memory_latency_list/size KB:4096 78.3 ns 86.0 ns 8000000 Nodes=64k Read Rate=709.721M/s
memory_latency_list/size KB:8192 79.9 ns 86.4 ns 6000000 Nodes=128k Read Rate=706.138M/s
memory_latency_list/size KB:16384 81.0 ns 86.9 ns 6000000 Nodes=256k Read Rate=702.06M/s
memory_latency_list/size KB:1 0.939 ns 1.01 ns 697000000 Nodes=16 Read Rate=59.1805G/s
memory_latency_list/size KB:2 1.56 ns 1.68 ns 417000000 Nodes=32 Read Rate=35.4984G/s
memory_latency_list/size KB:3 1.56 ns 1.68 ns 419000000 Nodes=48 Read Rate=35.4752G/s
memory_latency_list/size KB:4 1.56 ns 1.70 ns 417000000 Nodes=64 Read Rate=35.1392G/s
memory_latency_list/size KB:5 1.56 ns 1.68 ns 417000000 Nodes=80 Read Rate=35.4978G/s
memory_latency_list/size KB:6 1.56 ns 1.70 ns 418000000 Nodes=96 Read Rate=35.1338G/s
memory_latency_list/size KB:7 1.56 ns 1.68 ns 417000000 Nodes=112 Read Rate=35.4993G/s
memory_latency_list/size KB:8 1.56 ns 1.69 ns 416000000 Nodes=128 Read Rate=35.2361G/s
memory_latency_list/size KB:48 8.12 ns 8.72 ns 81000000 Nodes=768 Read Rate=6.83609G/s
memory_latency_list/size KB:64 8.14 ns 8.74 ns 81000000 Nodes=1024 Read Rate=6.82078G/s
memory_latency_list/size KB:80 8.13 ns 8.73 ns 80000000 Nodes=1.25k Read Rate=6.82641G/s
memory_latency_list/size KB:96 8.13 ns 8.72 ns 81000000 Nodes=1.5k Read Rate=6.83482G/s
memory_latency_list/size KB:112 8.13 ns 8.73 ns 81000000 Nodes=1.75k Read Rate=6.82553G/s
memory_latency_list/size KB:128 8.12 ns 8.72 ns 81000000 Nodes=2k Read Rate=6.83534G/s
memory_latency_list/size KB:144 8.12 ns 8.70 ns 81000000 Nodes=2.25k Read Rate=6.84724G/s
memory_latency_list/size KB:160 8.15 ns 8.78 ns 81000000 Nodes=2.5k Read Rate=6.78763G/s
memory_latency_list/size KB:512 8.14 ns 8.74 ns 81000000 Nodes=8k Read Rate=6.8183G/s
memory_latency_list/size KB:1024 23.5 ns 25.3 ns 59000000 Nodes=16k Read Rate=2.35875G/s
memory_latency_list/size KB:1536 43.3 ns 46.4 ns 11000000 Nodes=24k Read Rate=1.28456G/s
memory_latency_list/size KB:2048 58.4 ns 62.7 ns 10000000 Nodes=32k Read Rate=973.09M/s
memory_latency_list/size KB:2560 64.3 ns 69.1 ns 8000000 Nodes=40k Read Rate=883.186M/s
memory_latency_list/size KB:3072 70.7 ns 75.8 ns 9000000 Nodes=48k Read Rate=805.126M/s
memory_latency_list/size KB:3584 78.0 ns 83.9 ns 8000000 Nodes=56k Read Rate=727.891M/s
memory_latency_list/size KB:4096 77.3 ns 82.9 ns 8000000 Nodes=64k Read Rate=735.935M/s |
When running
| Code: | | sysbench memory --threads=4 --memory-total-size=128G --time=300 --memory-block-size=16K --memory-oper=read run |
| Code: | Running memory speed test with the following options:
block size: 16KiB
total size: 131072MiB
operation: read
scope: global
Initializing worker threads...
Threads started!
Total operations: 8388608 (4782472.19 per second)
[b]131072.00 MiB transferred (74726.13 MiB/sec)[/b]
General statistics:
total time: 1.7518s
total number of events: 8388608
Latency (ms):
min: 0.00
avg: 0.00
max: 6.30
95th percentile: 0.00
sum: 5739.60
Threads fairness:
events (avg/stddev): 2097152.0000/0.00
execution time (avg/stddev): 1.4349/0.00 |
When I bump the block size up to 512M, I approximately get ~7400-7600MiB/sec |
|
| Back to top |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Sat Aug 22, 2020 10:26 am Post subject: |
|
|
According to: https://github.com/speed47/spectre-meltdown-checker
(this is long...)
| Code: | Spectre and Meltdown mitigation detection tool v0.43
Checking for vulnerabilities on current system
Kernel is Linux 5.4.48-ck-RegFix #12 SMP PREEMPT Fri Aug 21 22:03:42 PDT 2020 x86_64
CPU is Intel(R) Core(TM)2 Quad CPU Q9400 @ 2.66GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: NO
* CPU indicates IBRS capability: NO
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: NO
* CPU indicates IBPB capability: NO
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: NO
* CPU indicates STIBP capability: NO
* Speculative Store Bypass Disable (SSBD)
* CPU indicates SSBD capability: NO
* L1 data cache invalidation
* FLUSH_CMD MSR is available: NO
* CPU indicates L1D flush capability: NO
* Microarchitectural Data Sampling
* VERW instruction is available: NO
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown/L1TF (RDCL_NO): NO
* CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO
* CPU/Hypervisor indicates L1D flushing is not necessary on this system: NO
* Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA): NO
* CPU explicitly indicates not being vulnerable to Microarchitectural Data Sampling (MDS_NO): NO
* CPU explicitly indicates not being vulnerable to TSX Asynchronous Abort (TAA_NO): NO
* CPU explicitly indicates not being vulnerable to iTLB Multihit (PSCHANGE_MSC_NO): NO
* CPU explicitly indicates having MSR for TSX control (TSX_CTRL_MSR): NO
* CPU supports Transactional Synchronization Extensions (TSX): NO
* CPU supports Software Guard Extensions (SGX): NO
* CPU supports Special Register Buffer Data Sampling (SRBDS): NO
* CPU microcode is known to cause stability problems: NO (family 0x6 model 0x17 stepping 0xa ucode 0xa0e cpuid 0x1067a)
* CPU microcode is the latest known available version: YES (latest version is 0xa0e dated 2015/07/29 according to builtin firmwares DB v148.20200603+i20200427)
* CPU vulnerability to the speculative execution attack variants
* Vulnerable to CVE-2017-5753 (Spectre Variant 1, bounds check bypass): YES
* Vulnerable to CVE-2017-5715 (Spectre Variant 2, branch target injection): YES
* Vulnerable to CVE-2017-5754 (Variant 3, Meltdown, rogue data cache load): YES
* Vulnerable to CVE-2018-3640 (Variant 3a, rogue system register read): YES
* Vulnerable to CVE-2018-3639 (Variant 4, speculative store bypass): YES
* Vulnerable to CVE-2018-3615 (Foreshadow (SGX), L1 terminal fault): NO
* Vulnerable to CVE-2018-3620 (Foreshadow-NG (OS), L1 terminal fault): YES
* Vulnerable to CVE-2018-3646 (Foreshadow-NG (VMM), L1 terminal fault): YES
* Vulnerable to CVE-2018-12126 (Fallout, microarchitectural store buffer data sampling (MSBDS)): YES
* Vulnerable to CVE-2018-12130 (ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)): YES
* Vulnerable to CVE-2018-12127 (RIDL, microarchitectural load port data sampling (MLPDS)): YES
* Vulnerable to CVE-2019-11091 (RIDL, microarchitectural data sampling uncacheable memory (MDSUM)): YES
* Vulnerable to CVE-2019-11135 (ZombieLoad V2, TSX Asynchronous Abort (TAA)): NO
* Vulnerable to CVE-2018-12207 (No eXcuses, iTLB Multihit, machine check exception on page size changes (MCEPSC)): YES
* Vulnerable to CVE-2020-0543 (Special Register Buffer Data Sampling (SRBDS)): NO
CVE-2017-5753 aka 'Spectre Variant 1, bounds check bypass'
* Mitigated according to the /sys interface: YES (Mitigation: usercopy/swapgs barriers and __user pointer sanitization)
* Kernel has array_index_mask_nospec: YES (1 occurrence(s) found of x86 64 bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
* Kernel has mask_nospec64 (arm64): NO
* Kernel has array_index_nospec (arm64): NO
> STATUS: NOT VULNERABLE (Mitigation: usercopy/swapgs barriers and __user pointer sanitization)
CVE-2017-5715 aka 'Spectre Variant 2, branch target injection'
* Mitigated according to the /sys interface: NO (Vulnerable, STIBP: disabled)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: NO
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: NO
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: NO
> STATUS: VULNERABLE (IBRS+IBPB or retpoline+IBPB is needed to mitigate the vulnerability)
CVE-2017-5754 aka 'Variant 3, Meltdown, rogue data cache load'
* Mitigated according to the /sys interface: YES (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Reduced performance impact of PTI: NO (PCID/INVPCID not supported, performance impact of PTI will be significant)
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)
CVE-2018-3640 aka 'Variant 3a, rogue system register read'
* CPU microcode mitigates the vulnerability: NO
> STATUS: VULNERABLE (an up-to-date CPU microcode is needed to mitigate this vulnerability)
CVE-2018-3639 aka 'Variant 4, speculative store bypass'
* Mitigated according to the /sys interface: NO (Vulnerable)
* Kernel supports disabling speculative store bypass (SSB): YES (found in /proc/self/status)
* SSB mitigation is enabled and active: NO
> STATUS: VULNERABLE (Your CPU doesn't support SSBD)
CVE-2018-3615 aka 'Foreshadow (SGX), L1 terminal fault'
* CPU microcode mitigates the vulnerability: N/A
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
CVE-2018-3620 aka 'Foreshadow-NG (OS), L1 terminal fault'
* Mitigated according to the /sys interface: YES (Mitigation: PTE Inversion; VMX: EPT disabled)
* Kernel supports PTE inversion: YES (found in kernel image)
* PTE inversion enabled and active: YES
> STATUS: NOT VULNERABLE (Mitigation: PTE Inversion; VMX: EPT disabled)
CVE-2018-3646 aka 'Foreshadow-NG (VMM), L1 terminal fault'
* Information from the /sys interface: Mitigation: PTE Inversion; VMX: EPT disabled
* This system is a host running a hypervisor: NO
* Mitigation 1 (KVM)
* EPT is disabled: YES
* Mitigation 2
* L1D flush is supported by kernel: YES (found flush_l1d in kernel image)
* L1D flush enabled: NO
* Hardware-backed L1D flush supported: NO (flush will be done in software, this is slower)
* Hyper-Threading (SMT) is enabled: NO
> STATUS: NOT VULNERABLE (this system is not running a hypervisor)
CVE-2018-12126 aka 'Fallout, microarchitectural store buffer data sampling (MSBDS)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Your kernel supports mitigation, but your CPU microcode also needs to be updated to mitigate the vulnerability)
CVE-2018-12130 aka 'ZombieLoad, microarchitectural fill buffer data sampling (MFBDS)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Your kernel supports mitigation, but your CPU microcode also needs to be updated to mitigate the vulnerability)
CVE-2018-12127 aka 'RIDL, microarchitectural load port data sampling (MLPDS)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Your kernel supports mitigation, but your CPU microcode also needs to be updated to mitigate the vulnerability)
CVE-2019-11091 aka 'RIDL, microarchitectural data sampling uncacheable memory (MDSUM)'
* Mitigated according to the /sys interface: NO (Vulnerable: Clear CPU buffers attempted, no microcode; SMT disabled)
* Kernel supports using MD_CLEAR mitigation: YES (found md_clear implementation evidence in kernel image)
* Kernel mitigation is enabled and active: NO
* SMT is either mitigated or disabled: YES
> STATUS: VULNERABLE (Your kernel supports mitigation, but your CPU microcode also needs to be updated to mitigate the vulnerability)
CVE-2019-11135 aka 'ZombieLoad V2, TSX Asynchronous Abort (TAA)'
* Mitigated according to the /sys interface: YES (Not affected)
* TAA mitigation is supported by kernel: YES (found tsx_async_abort in kernel image)
* TAA mitigation enabled and active: NO
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
CVE-2018-12207 aka 'No eXcuses, iTLB Multihit, machine check exception on page size changes (MCEPSC)'
* Mitigated according to the /sys interface: YES (KVM: Mitigation: Split huge pages)
* This system is a host running a hypervisor: NO
* iTLB Multihit mitigation is supported by kernel: YES (found itlb_multihit in kernel image)
* iTLB Multihit mitigation enabled and active: YES (KVM: Mitigation: Split huge pages)
> STATUS: NOT VULNERABLE (this system is not running a hypervisor)
CVE-2020-0543 aka 'Special Register Buffer Data Sampling (SRBDS)'
* Mitigated according to the /sys interface: YES (Not affected)
* SRBDS mitigation control is supported by the kernel: YES (found SRBDS implementation evidence in kernel image. Your kernel is up to date for SRBDS mitigation)
* SRBDS mitigation control is enabled and active: NO
> STATUS: NOT VULNERABLE (your CPU vendor reported your CPU model as not vulnerable)
> SUMMARY: CVE-2017-5753:OK CVE-2017-5715:KO CVE-2017-5754:OK CVE-2018-3640:KO CVE-2018-3639:KO CVE-2018-3615:OK CVE-2018-3620:OK CVE-2018-3646:OK CVE-2018-12126:KO CVE-2018-12130:KO CVE-2018-12127:KO CVE-2019-11091:KO CVE-2019-11135:OK CVE-2018-12207:OK CVE-2020-0543:OK
Need more detailed information about mitigation options? Use --explain
A false sense of security is worse than no security at all, see --disclaimer |
|
|
| Back to top |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Mon Aug 24, 2020 9:06 am Post subject: |
|
|
Since I was compiling for Core2, I didn't think this was something of significant note, but this could be the cause of my other missing "15%". When I built the first kernel in the liveCD environment, I hard the standard Gentoo options available for the newer Intel families. However, that dropped off at some point.
Instead of:
| Code: | # CONFIG_MK8 is not set
# CONFIG_MK8SSE3 is not set
# CONFIG_MK10 is not set
# CONFIG_MBARCELONA is not set
# CONFIG_MBOBCAT is not set
# CONFIG_MJAGUAR is not set
# CONFIG_MBULLDOZER is not set
# CONFIG_MPILEDRIVER is not set
# CONFIG_MSTEAMROLLER is not set
# CONFIG_MEXCAVATOR is not set
# CONFIG_MZEN is not set
# CONFIG_MPSC is not set
# CONFIG_MATOM is not set
# CONFIG_MCORE2 is not set
# CONFIG_MNEHALEM is not set
# CONFIG_MWESTMERE is not set
# CONFIG_MSILVERMONT is not set
# CONFIG_MSANDYBRIDGE is not set
# CONFIG_MIVYBRIDGE is not set
# CONFIG_MHASWELL is not set
# CONFIG_MBROADWELL is not set
# CONFIG_MSKYLAKE is not set
# CONFIG_MSKYLAKEX is not set
# CONFIG_MCANNONLAKE is not set
# CONFIG_MICELAKE is not set
CONFIG_MNATIVE=y |
I only have:
| Code: | # CONFIG_HYPERVISOR_GUEST is not set
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
CONFIG_MCORE2=y
# CONFIG_MATOM is not set
# CONFIG_GENERIC_CPU is not set |
I emerged gentoo-sources since I use ck-sources for MuQSS and a make defconfig/syncconfig resulted in the same thing. I can't seem to find a correlation that would have caused this to happen. FWIW the Q9400S has SSE4.1 instructions and I was planning on using "native", but alas...
I started this Gentoo build out from a clean install. I didn't even copy over my make.conf for portage. Do the -march and -tune settings carry over to kernel compilation on a "emerge -e @system" rebuild? |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54808
Location: 56N 3W
|
| Posted: Mon Aug 24, 2020 9:15 am Post subject: |
|
|
DigitalCorpus,
All those extra CPU types come from emerging the kernel with USE=experimental.
They are not standard. USE=experimental applies some patches to the kernel that Linus has not approved.
Kernel building does not use make.conf at all.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Mon Aug 24, 2020 12:27 pm Post subject: |
|
|
| NeddySeagoon wrote: | DigitalCorpus,
All those extra CPU types come from emerging the kernel with USE=experimental.
They are not standard. USE=experimental applies some patches to the kernel that Linus has not approved.
Kernel building does not use make.conf at all. |
Initially, no, they were not emerged with -experimental. I did actually change that via package.use on ck-sources and emerge -1 ck-sources, but that didn't change anything even with a syncconfig.
I tested this on gentoo-sources and had the same results. Simplest way was to remove the package and re-emerge it. Going to play with removing the .config file to see what causes this to "take" |
|
| Back to top |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Mon Aug 24, 2020 1:23 pm Post subject: |
|
|
| DigitalCorpus wrote: | | NeddySeagoon wrote: | DigitalCorpus,
All those extra CPU types come from emerging the kernel with USE=experimental.
They are not standard. USE=experimental applies some patches to the kernel that Linus has not approved.
Kernel building does not use make.conf at all. |
Initially, no, they were not emerged with -experimental. I did actually change that via package.use on ck-sources and emerge -1 ck-sources, but that didn't change anything even with a syncconfig.
I tested this on gentoo-sources and had the same results. Simplest way was to remove the package and re-emerge it. Going to play with removing the .config file to see what causes this to "take" |
After a bunch of emerge, emerge -1, emerge -C, et al, I copied my source directories from my backup. Turns out that ck-source was emerging and failing silently. Some portion of the Gentoo packages were silently failing and not applying "correctly". Then again, ck-sources is semi-unmaintained at the moment? I have the granularity of CPU generations selectable again. Going to do a Core2 build as a sanity check and then a native. I'll probably post an update around 1700-2000 PDT. I'll be surprised if my initial regression observation is resolved. Coincidently, the LiveCD/USB kernel is the same version as the last ck-sources in the portage tree. |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54808
Location: 56N 3W
|
| Posted: Mon Aug 24, 2020 3:54 pm Post subject: |
|
|
DigitalCorpus,
You can fiddle with the kernels gcc options on the make command line.
Read the Makefile.
Hint:
| Makefile: | # Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
KBUILD_CPPFLAGS += $(KCPPFLAGS)
KBUILD_AFLAGS += $(KAFLAGS)
KBUILD_CFLAGS += $(KCFLAGS) |
You get to keep all the pieces when it breaks
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Mon Aug 24, 2020 4:25 pm Post subject: |
|
|
| It's Gentoo, and Linux, running on comparatively ancient hardware in a non-production environment. I still have the USB drive plugged in. C'est la vie. Restored backups give proper options. Doing iterative testing to see if I can find the regression(s). 20-min per recompile. Thank you for the tip, though. |
|
| Back to top |
|
|
DigitalCorpus
Apprentice
Joined: 30 Jul 2007
Posts: 283
|
| Posted: Thu Aug 27, 2020 10:33 pm Post subject: |
|
|
As Jaglover noted over in https://forums.gentoo.org/viewtopic-t-1096442.html, even currently the USE flag experimental is not applying, but only if you've built a kernel from those sources. It's a "sticky" settings because you can emerge -C the sources, rm the left over directory, reboot, and emerge the sources again and the patches will still not apply. Doing a bit too much to muck with it, so I'm just syncconfig-ing my working ck-sources with the iterative config file I'm working with and testing for the regressions. Turns out, I misremembered and the LiveCD vs initial build was only ~7% loss. Either way...
Also, this current issue is still separate from why disabling USB_PCI lops off performance like a machete cutting a watermelon. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Kernel & Hardware
