As with kernel 3.9 (regardless if vanilla or grsecurity patched, from 3.9.0 to 3.9.2 tested) the portage's "Calculating dependencies" take ages, like 5 to 7 minutes on i5 sandybridge cpu. Even after first run if I ^C it and start again, on 3.8 and lower, it takes up to 3s, on 3.9 it does take again 5 to 7 minutes. I am not the only one who noticed such thing. Also 'installing' part take ages, with yasm, where's only a few files, it took almost minute! Anyone can confirm it? I do run gentoo over dmcrypted lvm, ext4 fs.
After disabling everything that had anything to do with debuging (almost) the emerge is no longer that slow, still noticable slow than with 3.8 but 'emerge -pv apachce' after coldboot finish in less than 30s and re-doing it finish in about 5s.
Just tried 3.9.2 with hardened patches and almost no debugging features. You're right - something's fishy here. * When the kernel starts to boot, I get: "BUG: unable to handle kernel", a couple Oops'es, a couple "CPU stuck?" warnings. * The system then boots and exhibits momentary hiccups (remains stuck for a fraction of a second) every now and then. * I only see 1 CPU (instead of 4). * The CPU temperature is very high all the time, despite a low loadavg. * emerge performs about twice as slow; nothing so extraordinary here.
3.9 seems to be broken hard. I had two kernel panics with cpuidle intel p-state drivers http://i.imgur.com/wo7Xa7d.jpg That's the worst major kernel version in years. I wonder if it shoudn't be locked to ~arch for a long time.
Major releases are supposed to be the worst since they come with new features, that's why we try to avoid stabilizing early kernels in a branch unless there is a good reason to do so. We're going to have this bug to be a bit more specific; as this seems to have to do something regarding P state drivers, can you test the dependency calculation with and without those? Does turning it off make a difference? Also, what do you have set as the CPU frequence governer? Can you try different ones here too? You can switch them on the fly. See below link for more information on them. https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt (In reply to comment #2) > Just tried 3.9.2 with hardened patches and almost no debugging features. > You're right - something's fishy here. Ugh, that's quite a list. Can you try the same suggestion as above? If things are still happening without those P state drivers, can you file separate bugs for the problems you are experiencing?
Turns out that the worst issues are caused by X2APIC in my case. I opened that as bug 470792. Piotr, try that out too maybe.
Sadly, I did not had X2APIC enabled. About P-state, I did disabled it and didnt noticed kernel panics anymore, but the emerge still seems to be noticable slower (twice or a bit more). With p-state enabled, even when i had ondemand enabled in kernel and as default, there was no ondemand option, default was 'powersave' but driver was 'pstate', the cpufreq was like with ondemand but much faster switching to highter/lower freqs which is imo good idea. Switching cpu governors did not take any effect to the issue. What's interesing is that most of the time with 'Calculating dependencie' the cpu usage is below 10% and it takes so long
3.9.3 contains some sched, cpufreq and intel_pstate fixes; could you please try those to see if these issues have been resolved already? https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.9.3 I also see a relevant ML thread about this, but that's for 3.10-rc1. http://thread.gmane.org/gmane.linux.kernel/1493293
Running 3.9.3 now, after some of tests after coldboots with minimal services and no X, I can say that at this very moment performance of emerge is the same as with 3.8.x. Re p-state kernel panics, so far didnt had one, but it's random so I will let you know if my system crash again, if no - then presume that there's no more issue with cpuidle crashes when pstate is enabled.
Piotr, do you happen to have CONFIG_MAXSMP=y? It's another source of my problems with 3.9.
Oh, you've got it fixed, sorry. :)
Yeah, fixed. ;-) MAXSMP is not set. to be honest, my kernel config was started with 'make allnoconfig' so if anything is enabled its either because I had a reason to enable it or it was a dep of another needed option. ;-)
If you experience this again then please reopen the bug.
