Hello Im Filling this bug here Because i Did a Git Bisect between the kernel 4.4 which is fine and faster and the kernel 4.5-rc1 which introduced the slowness all the way up to 4.10-rc5 and this is what i get : By Slowness Im Talking About Slow Compile Time And 3d Games Slow as hell. On The kernel 4.1.37 and 4.4.44 i can compile the kernel Sources in 13 Minutes. And With The kernel 4.9.6 which is the last stable in almost 30 Minutes. Both's kernels with the governor Performance set . And Slow 3d Games For Example the games on ppsspp emulator are too Slow. Tested With Kernels 4.5-rc1 to 4.10-rc5 all of them are slow. With the kernels 4.1 lts and 4.4 lts the games are normal . Bisecting: 5556 revisions left to test after this (roughly 13 steps) #GOOD# [1289ace5b4f70f1e68ce785735b82c7e483de863] Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi Bisecting: 2483 revisions left to test after this (roughly 12 steps) #BAD# [984065055e6e39f8dd812529e11922374bd39352] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux Bisecting: 1192 revisions left to test after this (roughly 11 steps) #BAD# [a016af2e70bfca23f2f5de7d8708157b86ea374d] Merge tag 'sound-4.5-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound Bisecting: 966 revisions left to test after this (roughly 10 steps) #GOOD# [d45187aaf0e256d23da2f7694a7826524499aa31] Merge branch 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging Bisecting: 522 revisions left to test after this (roughly 9 steps) #GOOD# [d0021d3bdfe9d551859bca1f58da0e6be8e26043] Merge remote-tracking branch 'asoc/topic/wm8960' into asoc-next Bisecting: 273 revisions left to test after this (roughly 8 steps) #BAD# [0bdf5a05647a66dcc6394986e061daeac9b1cf96] drm/i915: Add reverse mapping between port and intel_encoder Bisecting: 124 revisions left to test after this (roughly 7 steps) #GOOD# [6a6582bfff39f099d0867e8b97b409efd1d84b9a] drm/i915/gen9: extract parse_csr_fw Bisecting: 62 revisions left to test after this (roughly 6 steps) #GOOD# [ab75bb5d852cf9a877a973c2174e7791d92554c5] drm/i915: Turn vgpu pdps into an array Bisecting: 31 revisions left to test after this (roughly 5 steps) #GOOD# [1494276000db789c6d2acd85747be4707051c801] drm/atomic-helper: Implement subsystem-level suspend/resume Bisecting: 15 revisions left to test after this (roughly 4 steps) #BAD# [ce7f172856396d92e82cb0eae420f4ce41c92851] drm/i915: Fix i915_ggtt_view_equal to handle rotation correctly Bisecting: 7 revisions left to test after this (roughly 3 steps) #BAD# [81e4e0c95d37d020e18268bdd58f208bb5259713] drm/i915: Send TP1 TP2/3 even when panel claims no NO_TRAIN_ON_EXIT. Bisecting: 3 revisions left to test after this (roughly 2 steps) #BAD# [f0f59a00a1c9be11038bef5aa735ed7dd985f9cf] drm/i915: Type safe register read/write Bisecting: 1 revision left to test after this (roughly 1 step) #GOOD# [0670c5a688122c66ecfb0bd8cbd8067cc971a4e8] drm/i915: Add 'offset' to uncore funcs Bisecting: 0 revisions left to test after this (roughly 0 steps) #GOOD# [9bca5d0ca76c0ce029e2b43cf081863e7e8f6768] drm/i915: Add missing ')' to SKL_PS_ECC_STAT define f0f59a00a1c9be11038bef5aa735ed7dd985f9cf is the first bad commit commit f0f59a00a1c9be11038bef5aa735ed7dd985f9cf Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Nov 18 15:33:26 2015 +0200 drm/i915: Type safe register read/write Make I915_READ and I915_WRITE more type safe by wrapping the register offset in a struct. This should eliminate most of the fumbles we've had with misplaced parens. This only takes care of normal mmio registers. We could extend the idea to other register types and define each with its own struct. That way you wouldn't be able to accidentally pass the wrong thing to a specific register access function. The gpio_reg setup is probably the ugliest thing left. But I figure I'd just leave it for now, and wait for some divine inspiration to strike before making it nice. As for the generated code, it's actually a bit better sometimes. Eg. looking at i915_irq_handler(), we can see the following change: lea 0x70024(%rdx,%rax,1),%r9d mov $0x1,%edx - movslq %r9d,%r9 - mov %r9,%rsi - mov %r9,-0x58(%rbp) - callq *0xd8(%rbx) + mov %r9d,%esi + mov %r9d,-0x48(%rbp) callq *0xd8(%rbx) So previously gcc thought the register offset might be signed and decided to sign extend it, just in case. The rest appears to be mostly just minor shuffling of instructions. v2: i915_mmio_reg_{offset,equal,valid}() helpers added s/_REG/_MMIO/ in the register defines mo more switch statements left to worry about ring_emit stuff got sorted in a prep patch cmd parser, lrc context and w/a batch buildup also in prep patch vgpu stuff cleaned up and moved to a prep patch all other unrelated changes split out v3: Rebased due to BXT DSI/BLC, MOCS, etc. v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com :040000 040000 c0e5d868baa9f128af701fa0642d9c1551ee415c 1fbd83167b2645ee34dfd626b8c38f15114d45d6 M drivers This is My machine : inxi -F System: Host: darkmaza Kernel: 4.1.37 x86_64 (64 bit) Desktop: MATE 1.16.1 Distro: Gentoo Base System release 2.3 Machine: Device: laptop System: TOSHIBA product: PORTEGE R700 v: PT310U-0K002Y01 serial: 3B053928H Mobo: TOSHIBA model: Portable PC v: Version A0 serial: 0000000000 BIOS: TOSHIBA v: Version 2.20 date: 12/22/2011 CPU: Dual core Intel Core i3 M 380 (-HT-MCP-) cache: 3072 KB clock speeds: max: 2533 MHz 1: 933 MHz 2: 933 MHz 3: 1333 MHz 4: 1866 MHz Graphics: Card: Intel Core Processor Integrated Graphics Controller Display Server: X.org 1.19.1 driver: intel tty size: 135x30 Advanced Data: N/A for root Audio: Card Intel 5 Series/3400 Series High Definition Audio driver: snd_hda_intel Sound: ALSA v: k4.1.37-ck Network: Card: Intel Wireless 7260 driver: iwlwifi IF: wlp2s0 state: up mac: f0:42:1c:c7:07:59 Drives: HDD Total Size: 320.1GB (1.6% used) ID-1: /dev/sda model: WDC_WD3200BEKT size: 320.1GB Partition: ID-1: / size: 88G used: 55G (63%) fs: zfs dev: N/A ID-2: swap-1 size: 4.55GB used: 0.00GB (0%) fs: swap dev: /dev/sda2 ID-3: swap-2 size: 0.19GB used: 0.00GB (0%) fs: swap dev: /dev/zram0 ID-4: swap-3 size: 0.19GB used: 0.00GB (0%) fs: swap dev: /dev/zram1 ID-5: swap-4 size: 0.19GB used: 0.00GB (0%) fs: swap dev: /dev/zram2 ID-6: swap-5 size: 0.19GB used: 0.00GB (0%) fs: swap dev: /dev/zram3 Sensors: System Temperatures: cpu: 56.0C mobo: N/A Fan Speeds (in rpm): cpu: N/A Info: Processes: 242 Uptime: 59 min Memory: 2036.8/3681.4MB Client: Shell (fish) inxi: 2.3.4 LSPCI : 00:00.0 Host bridge: Intel Corporation Core Processor DRAM Controller (rev 02) 00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) 00:16.0 Communication controller: Intel Corporation 5 Series/3400 Series Chipset HECI Controller (rev 06) 00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06) 00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 06) 00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 (rev 06) 00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 2 (rev 06) 00:1c.2 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 3 (rev 06) 00:1c.3 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 4 (rev 06) 00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller (rev 06) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev a6) 00:1f.0 ISA bridge: Intel Corporation HM55 Chipset LPC Interface Controller (rev 06) 00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA AHCI Controller (rev 06) 00:1f.6 Signal processing controller: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem (rev 06) 01:00.0 SD Host controller: Ricoh Co Ltd MMC/SD Host Controller (rev 01) 02:00.0 Network controller: Intel Corporation Wireless 7260 (rev bb) ff:00.0 Host bridge: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers (rev 02) ff:00.1 Host bridge: Intel Corporation Core Processor QuickPath Architecture System Address Decoder (rev 02) ff:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 02) ff:02.1 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor QPI Physical 0 (rev 02) ff:02.2 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor Reserved (rev 02) ff:02.3 Host bridge: Intel Corporation 1st Generation Core i3/5/7 Processor Reserved (rev 02)
Please Help Me Here What I can Do. Thanks in advance.
I'm pretty sure the git bisect result is not right. Since that one is probably impossible to revert, you should try building the supposedly good commit before that (i.e. f0f59a00a1c9be^) and the supposedly bad commit, and verify the bisect.
Ok Will Do Compile Those Commits Thanks.
I taked the cloned kernel git repo unmodified an I did git reset --hard f0f59a00a1c9be11038bef5aa735ed7dd985f9cf to verufy is the bug is there.
One Question on the git kernel cloned repo unmodified when i do git log and i hit / to search for f0f59a00a1c9be11038bef5aa735ed7dd985f9cf the commot before this one is 4fe5dc4873663fc4cfbdae7a45a1b4378a2d7993 arm64: dts: Enable HS200 mode operation on exynos7-espresso and when i do git reset --hard f0f59a00a1c9be11038bef5aa735ed7dd985f9cf the git log shows that the commit before is 9bca5d0ca76c0ce029e2b43cf081863e7e8f6768 drm/i915: Add missing ')' to SKL_PS_ECC_STAT define which one of the commits before f0f59a00a1c9be11038bef5aa735ed7dd985f9cf i have to compile ?
When You Say : I'm pretty sure the git bisect result is not right. Since that one is probably impossible to revert, you should try building the supposedly good commit before that (i.e. f0f59a00a1c9be^) and the supposedly bad commit, and verify the bisect. "the supposedly good commit before that" which good commit ?
Confirmed the Bug/Regression is on Bisecting: 3 revisions left to test after this (roughly 2 steps) #BAD# [f0f59a00a1c9be11038bef5aa735ed7dd985f9cf] drm/i915: Type safe register read/write Linux darkmaza 4.3.0-rc3+ #1 SMP PREEMPT Sat Jan 28 14:18:52 AST 2017 x86_64 Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz GenuineIntel GNU/Linux
Created attachment 129199 [details] DMESG kernel 4.3.0-rc3+ with Regression/Bug Slowness commit f0f59a00a1c9be11038bef5aa735ed7dd985f9cf
The Git Bisect I did is not wrong im pretty sure is ok i fallow this guide https://wiki.gentoo.org/wiki/Kernel_git-bisect very nice and i build 13 kernels wasting my cpu cycles . This need to be fixed I dont know how but there has to be a solution for this problem i hope some one can help me . Thanks in Advance.
1) Build 9bca5d0ca76c ("drm/i915: Add missing ')' to SKL_PS_ECC_STAT define") and see if that commit is good or bad. 2) Build f0f59a00a1c9 ("drm/i915: Type safe register read/write") and see if that commit is good or bad.
(In reply to Carlos Jimenez from comment #7) > Confirmed the Bug/Regression is on Bisecting: 3 revisions left to test after > this (roughly 2 steps) > #BAD# [f0f59a00a1c9be11038bef5aa735ed7dd985f9cf] drm/i915: Type safe > register read/write > > > Linux darkmaza 4.3.0-rc3+ #1 SMP PREEMPT Sat Jan 28 14:18:52 AST 2017 x86_64 > Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz GenuineIntel GNU/Linux And this "4.3.0-rc3+" is bogus, because the commit you claim is bad was first merged in v4.5-rc1.
Doing git reset --hard 9bca5d0ca76c0ce029e2b43cf081863e7e8f6768 1) Build 9bca5d0ca76c ("drm/i915: Add missing ')' to SKL_PS_ECC_STAT define") and see if that commit is good or bad. Im Going To Build It i just did what you told me 2) Build f0f59a00a1c9 ("drm/i915: Type safe register read/write") and see if that commit is good or bad. and i confirmed this commit has the bug Why "And this "4.3.0-rc3+" is bogus, because the commit you claim is bad was first merged in v4.5-rc1." i did git reset --hard f0f59a00a1c9be11038bef5aa735ed7dd985f9cf and git checkout the kernel 4.3.0-rc3+ so what is wrong ?????? this is a unmodified git repo . And git reset --hard 9bca5d0ca76c0ce029e2b43cf081863e7e8f6768 Checking out files: 100% (35/35), done. HEAD is now at 9bca5d0ca76c drm/i915: Add missing ')' to SKL_PS_ECC_STAT define Checkout The kernel VERSION = 4 PATCHLEVEL = 3 SUBLEVEL = 0 EXTRAVERSION = -rc3 NAME = Hurr durr I'ma sheep Too And Im Gonna Build it again which was already compiled by the git bisect . to confirm what we already know is GOOD
Here is Something To Know tag name v4.5-rc1 (b13adfcdf288a00a7e58556f326ecb56fbb53b92) tag date 2016-01-24 21:06:57 (GMT) tagged by Linus Torvalds <torvalds@linux-foundation.org> tagged object \ f0f59a00a1c9be11038bef5aa735ed7dd985f9cf is the first bad commit commit f0f59a00a1c9be11038bef5aa735ed7dd985f9cf Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Nov 18 15:33:26 2015 +0200 look at the dates excuseme if im wrong but how f0f59a00a1c9be11038bef5aa735ed7dd985f9cf whas merged in the v4.5-rc1 which dates to 2016-01-24 21:06:57 and the commit Date: Wed Nov 18 15:33:26 2015 +0200 ?
Commit 9bca5d0ca76c0ce029e2b43cf081863e7e8f6768 drm/i915: Add missing ')' to SKL_PS_ECC_STAT define Confirmed As Good Commit here Linux darkmaza 4.3.0-rc3+ #1 SMP PREEMPT Sat Jan 28 16:46:21 AST 2017 x86_64 Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz GenuineIntel GNU/Linux
Created attachment 129200 [details] DMESG kernel 4.3.0-rc3+ with NO Regression/Bug Slowness commit 9bca5d0ca76c0ce029e2b43cf081863e7e8f6768
(In reply to Jani Nikula from comment #10) > 1) Build 9bca5d0ca76c ("drm/i915: Add missing ')' to SKL_PS_ECC_STAT > define") and see if that commit is good or bad. > > 2) Build f0f59a00a1c9 ("drm/i915: Type safe register read/write") and see if > that commit is good or bad. DONE AND DONE
What Else I Need To Do To Prove there is a Regression In The Kernel Which Is Affecting Me And Maybe Other People.
Created attachment 129204 [details] Kernel Build With kernel 4.10-rc5 i915 disabled vesafb enabled Compiled kernel in 12 minutes This Test i did with the kernel 4.10-rc5 proves that the slowness is caused by the intel drm i915 driver .
(In reply to Carlos Jimenez from comment #18) > Created attachment 129204 [details] > Kernel Build With kernel 4.10-rc5 i915 disabled vesafb enabled Compiled > kernel in 12 minutes > > This Test i did with the kernel 4.10-rc5 proves that the slowness is caused > by the intel drm i915 driver . In the Console
CLOSING THIS BUG
Carlos you may drop this bug if you want, but a little patience would be appreciated. Present the facts, what are the "make clean && time make -j3" timings for that pair of kernels? Do you have intel_ips compiled in on later kernels? What does powertop report during the compilations?
I gave this a quick whirl on my ILK but didn't see any performance changes whatsoever. Long ago I tried to figure out what IPS was doing on that particular machine, and at the time it seemed to be always thermally limited as soon as the GPU became active. So without tracing the IPS stuff again I can't actually say with 100% certainty that there isn't any change in the behaviour. I might do that at some point if I get bored enough. I did re-read the patch several times, but I still can't spot any functional changes in there.
I haven't noticed anything unusual yet on my ilk (but that has a dead cpu fan!), but I've been mostly concentrating on fixing up gem tests.
Ville & Chris - Do you have some concrete ideas on this? To be or not to be...
Reporter, do you still have issues or some comments?
No feedback and cannot be reproduced by Ville/Chris.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.