Re: tracking down sources of spin cpu%
On Wed, Jul 25, 2018 at 10:33:48PM +0100, Stuart Henderson wrote: > On 2018/07/25 22:57, Alexandre Ratchov wrote: > > On Wed, Jul 25, 2018 at 05:10:05PM +0100, Stuart Henderson wrote: > > > On 2018/07/25 15:26, Alexandre Ratchov wrote: > > > > On Wed, Jul 25, 2018 at 11:56:04AM +0100, Stuart Henderson wrote: > > > > > On 2018/07/25 12:00, Antoine Jacoutot wrote: > > > > > > > I see the exact same issue as you do. > > > > > > > I'll try with s/modesetting/intel and see if it improves things. > > > > > > > > > > > > OK I can already confirm this "fixes" the issue for me. > > > > > > > > > > It's been up for long enough now that I agree. > > > > > > > > > > For anyone else running into this, here is the xorg.conf stanza to > > > > > switch (no other entries are needed in the file). > > > > > > > > > > Section "Device" > > > > >Identifier "Intel Graphics" > > > > >Driver "intel" > > > > > EndSection > > > > > > > > > > > > > Do you remember if the problem occurs with the modesetting driver if > > > > you disable acceleration, ie you add: > > > > > > > > Option "AccelMethod" "none" > > > > > > > > to the "Device" section? > > > > > > > > > > I hadn't tried that before. I just gave it a go, didn't see any freezes, > > > but browser rendering was so slow as to be useless - Firefox took about > > > 10 minutes to get to a state where I could interact with it (didn't help > > > that the saved open tab was a complex map I suppose) and ~30 seconds to > > > react to anything. chromium wasn't quite as bad, but I couldn't live > > > with it. > > > > This is strange, firefox starts almost immediately on both of my > > machines (~1.5s on the faster one, i5-2500K) , with: > > > > Section "Device" > > Identifier "Card0" > > Driver "modesetting" > > Option "SWcursor" "on" > > Option "AccelMethod" "none" > > EndSection > > > > AFAIU, if AccelMethod is set to none, the device behaves like a bare > > framebuffer (given "modern" memory speeds, this covers all desktop > > needs, ex. mplayer uses ~6% CPU for a full-screen 720p movie). So, > > what you observe may be unrelated to graphics. Which processes consume > > CPU and appear to spin? > > > > With 'Driver modesetting / AccelMethod none' the busiest firefox process > uses 100-200% cpu while it's loading saved tabs etc, and this takes ~10 > minutes. > > With 'Driver intel' it loads the same tabs and starts responding in > about 10 seconds. > > With no xorg.conf, so 'Driver modesetting' and default AccelMethod, > it loads tabs and starts responding reasonably quickly (I'm not going > back to it to check now, but probably also about 10 seconds), but I get > freezes very often. > > Anyway unless somebody has a particular request that will help track > down what's going on, I'll stick with intel, as it significantly reduces > the risk of me wanting to hammer a screwdriver through the monitors (or, > possibly worse, consider buying a Mac) if I'm trying to actually get > anything done :) I share the sentiment, been having lockups and other weirdness on radeon as well.. sent a report, I assume it may be similarly spinning, but have no idea how to debug this and only got "me toos" from other users.. :( -Bryan.
Re: tracking down sources of spin cpu%
On 2018/07/25 22:57, Alexandre Ratchov wrote: > On Wed, Jul 25, 2018 at 05:10:05PM +0100, Stuart Henderson wrote: > > On 2018/07/25 15:26, Alexandre Ratchov wrote: > > > On Wed, Jul 25, 2018 at 11:56:04AM +0100, Stuart Henderson wrote: > > > > On 2018/07/25 12:00, Antoine Jacoutot wrote: > > > > > > I see the exact same issue as you do. > > > > > > I'll try with s/modesetting/intel and see if it improves things. > > > > > > > > > > OK I can already confirm this "fixes" the issue for me. > > > > > > > > It's been up for long enough now that I agree. > > > > > > > > For anyone else running into this, here is the xorg.conf stanza to > > > > switch (no other entries are needed in the file). > > > > > > > > Section "Device" > > > >Identifier "Intel Graphics" > > > >Driver "intel" > > > > EndSection > > > > > > > > > > Do you remember if the problem occurs with the modesetting driver if > > > you disable acceleration, ie you add: > > > > > > Option "AccelMethod" "none" > > > > > > to the "Device" section? > > > > > > > I hadn't tried that before. I just gave it a go, didn't see any freezes, > > but browser rendering was so slow as to be useless - Firefox took about > > 10 minutes to get to a state where I could interact with it (didn't help > > that the saved open tab was a complex map I suppose) and ~30 seconds to > > react to anything. chromium wasn't quite as bad, but I couldn't live > > with it. > > This is strange, firefox starts almost immediately on both of my > machines (~1.5s on the faster one, i5-2500K) , with: > > Section "Device" > Identifier "Card0" > Driver "modesetting" > Option "SWcursor" "on" > Option "AccelMethod" "none" > EndSection > > AFAIU, if AccelMethod is set to none, the device behaves like a bare > framebuffer (given "modern" memory speeds, this covers all desktop > needs, ex. mplayer uses ~6% CPU for a full-screen 720p movie). So, > what you observe may be unrelated to graphics. Which processes consume > CPU and appear to spin? > With 'Driver modesetting / AccelMethod none' the busiest firefox process uses 100-200% cpu while it's loading saved tabs etc, and this takes ~10 minutes. With 'Driver intel' it loads the same tabs and starts responding in about 10 seconds. With no xorg.conf, so 'Driver modesetting' and default AccelMethod, it loads tabs and starts responding reasonably quickly (I'm not going back to it to check now, but probably also about 10 seconds), but I get freezes very often. Anyway unless somebody has a particular request that will help track down what's going on, I'll stick with intel, as it significantly reduces the risk of me wanting to hammer a screwdriver through the monitors (or, possibly worse, consider buying a Mac) if I'm trying to actually get anything done :)
Re: tracking down sources of spin cpu%
On Wed, Jul 25, 2018 at 05:10:05PM +0100, Stuart Henderson wrote: > On 2018/07/25 15:26, Alexandre Ratchov wrote: > > On Wed, Jul 25, 2018 at 11:56:04AM +0100, Stuart Henderson wrote: > > > On 2018/07/25 12:00, Antoine Jacoutot wrote: > > > > > I see the exact same issue as you do. > > > > > I'll try with s/modesetting/intel and see if it improves things. > > > > > > > > OK I can already confirm this "fixes" the issue for me. > > > > > > It's been up for long enough now that I agree. > > > > > > For anyone else running into this, here is the xorg.conf stanza to > > > switch (no other entries are needed in the file). > > > > > > Section "Device" > > >Identifier "Intel Graphics" > > >Driver "intel" > > > EndSection > > > > > > > Do you remember if the problem occurs with the modesetting driver if > > you disable acceleration, ie you add: > > > > Option "AccelMethod" "none" > > > > to the "Device" section? > > > > I hadn't tried that before. I just gave it a go, didn't see any freezes, > but browser rendering was so slow as to be useless - Firefox took about > 10 minutes to get to a state where I could interact with it (didn't help > that the saved open tab was a complex map I suppose) and ~30 seconds to > react to anything. chromium wasn't quite as bad, but I couldn't live > with it. This is strange, firefox starts almost immediately on both of my machines (~1.5s on the faster one, i5-2500K) , with: Section "Device" Identifier "Card0" Driver "modesetting" Option "SWcursor" "on" Option "AccelMethod" "none" EndSection AFAIU, if AccelMethod is set to none, the device behaves like a bare framebuffer (given "modern" memory speeds, this covers all desktop needs, ex. mplayer uses ~6% CPU for a full-screen 720p movie). So, what you observe may be unrelated to graphics. Which processes consume CPU and appear to spin?
Re: tracking down sources of spin cpu%
On 2018/07/25 15:26, Alexandre Ratchov wrote: > On Wed, Jul 25, 2018 at 11:56:04AM +0100, Stuart Henderson wrote: > > On 2018/07/25 12:00, Antoine Jacoutot wrote: > > > > I see the exact same issue as you do. > > > > I'll try with s/modesetting/intel and see if it improves things. > > > > > > OK I can already confirm this "fixes" the issue for me. > > > > It's been up for long enough now that I agree. > > > > For anyone else running into this, here is the xorg.conf stanza to > > switch (no other entries are needed in the file). > > > > Section "Device" > >Identifier "Intel Graphics" > >Driver "intel" > > EndSection > > > > Do you remember if the problem occurs with the modesetting driver if > you disable acceleration, ie you add: > > Option "AccelMethod" "none" > > to the "Device" section? > I hadn't tried that before. I just gave it a go, didn't see any freezes, but browser rendering was so slow as to be useless - Firefox took about 10 minutes to get to a state where I could interact with it (didn't help that the saved open tab was a complex map I suppose) and ~30 seconds to react to anything. chromium wasn't quite as bad, but I couldn't live with it.
Re: tracking down sources of spin cpu%
On Wed, Jul 25, 2018 at 11:56:04AM +0100, Stuart Henderson wrote: > On 2018/07/25 12:00, Antoine Jacoutot wrote: > > > I see the exact same issue as you do. > > > I'll try with s/modesetting/intel and see if it improves things. > > > > OK I can already confirm this "fixes" the issue for me. > > It's been up for long enough now that I agree. > > For anyone else running into this, here is the xorg.conf stanza to > switch (no other entries are needed in the file). > > Section "Device" >Identifier "Intel Graphics" >Driver "intel" > EndSection > Do you remember if the problem occurs with the modesetting driver if you disable acceleration, ie you add: Option "AccelMethod" "none" to the "Device" section?
Re: tracking down sources of spin cpu%
On 2018/07/25 12:00, Antoine Jacoutot wrote: > > I see the exact same issue as you do. > > I'll try with s/modesetting/intel and see if it improves things. > > OK I can already confirm this "fixes" the issue for me. It's been up for long enough now that I agree. For anyone else running into this, here is the xorg.conf stanza to switch (no other entries are needed in the file). Section "Device" Identifier "Intel Graphics" Driver "intel" EndSection
Re: tracking down sources of spin cpu%
> I see the exact same issue as you do. > I'll try with s/modesetting/intel and see if it improves things. OK I can already confirm this "fixes" the issue for me. -- Antoine
Re: tracking down sources of spin cpu%
On Wed, Jul 25, 2018 at 10:22:15AM +0100, Stuart Henderson wrote: > On 2018/07/24 23:07, Stuart Henderson wrote: > > My workstation is freezing up a lot again (usually in 30-60ish second > > bursts with no or very slow response to mouse or keyboard or screen > > updates). > > > > I have a status bar (xstatbar) that displays a graph of the last minute > > or so's cpu% split off into user/nice/system/spin/interrupt/idle. It > > skips a lot of updates when the machine freezes but it's obvious that > > it's mostly in spin. > > > > It seems particularly likely to occur when opening browser tabs. > > > > Is there anything sane that I can do (ahead of time, as I can't type > > when it's in that state) that will give clues about what's going on? > > I had a think about what might have changed when it started freezing > again and remembered that I had switched X back to modesetting at a time > which would roughly correlate with this (I had been using intel(4) to > cope with vncviewer problems, and switched back after jcs enabled SHM > in vncviewer). > > I've moved back to intel(4) now to see if this removes/reduces the > problem. Haven't run into one since, but it's still a bit early to say > if it's actually helped. > > (intel does remove one other annoyance, for some inexplicable reason > context menus like the right-click menu in browsers often show up on the > wrong monitor with modesetting..). I see the exact same issue as you do. I'll try with s/modesetting/intel and see if it improves things. -- Antoine
Re: tracking down sources of spin cpu%
On 2018/07/24 23:07, Stuart Henderson wrote: > My workstation is freezing up a lot again (usually in 30-60ish second > bursts with no or very slow response to mouse or keyboard or screen > updates). > > I have a status bar (xstatbar) that displays a graph of the last minute > or so's cpu% split off into user/nice/system/spin/interrupt/idle. It > skips a lot of updates when the machine freezes but it's obvious that > it's mostly in spin. > > It seems particularly likely to occur when opening browser tabs. > > Is there anything sane that I can do (ahead of time, as I can't type > when it's in that state) that will give clues about what's going on? I had a think about what might have changed when it started freezing again and remembered that I had switched X back to modesetting at a time which would roughly correlate with this (I had been using intel(4) to cope with vncviewer problems, and switched back after jcs enabled SHM in vncviewer). I've moved back to intel(4) now to see if this removes/reduces the problem. Haven't run into one since, but it's still a bit early to say if it's actually helped. (intel does remove one other annoyance, for some inexplicable reason context menus like the right-click menu in browsers often show up on the wrong monitor with modesetting..).
tracking down sources of spin cpu%
My workstation is freezing up a lot again (usually in 30-60ish second bursts with no or very slow response to mouse or keyboard or screen updates). I have a status bar (xstatbar) that displays a graph of the last minute or so's cpu% split off into user/nice/system/spin/interrupt/idle. It skips a lot of updates when the machine freezes but it's obvious that it's mostly in spin. It seems particularly likely to occur when opening browser tabs. Is there anything sane that I can do (ahead of time, as I can't type when it's in that state) that will give clues about what's going on? dmesg below, FWIW. OpenBSD 6.3-current (GENERIC.MP) #11: Fri Jul 20 14:48:58 BST 2018 st...@symphytum.spacehopper.org:/src/cvs-openbsd/sys/arch/amd64/compile/GENERIC.MP real mem = 17067200512 (16276MB) avail mem = 16540782592 (15774MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xec400 (92 entries) bios0: vendor Dell Inc. version "A12" date 05/11/2017 bios0: Dell Inc. PowerEdge T20 acpi0 at bios0: rev 2 acpi0: sleep states S0 S4 S5 acpi0: tables DSDT FACP APIC FPDT SLIC LPIT SSDT SSDT SSDT HPET SSDT MCFG SSDT ASF! DMAR acpi0: wakeup devices UAR1(S4) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) PXSX(S4) RP05(S4) PXSX(S4) PXSX(S4) PXSX(S4) GLAN(S4) EHC1(S3) EHC2(S3) XHC_(S4) HDEF(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.57 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.15 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.15 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Xeon(R) CPU E3-1225 v3 @ 3.20GHz, 3392.15 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins acpihpet0 at acpi0: 14318179 Hz acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (RP01) acpiprt2 at acpi0: bus 2 (RP02) acpiprt3 at acpi0: bus 4 (RP05) acpiprt4 at acpi0: bus -1 (PEG0) acpiprt5 at acpi0: bus -1 (PEG1) acpiprt6 at acpi0: bus -1 (PEG2) acpiec0 at acpi0: not present acpicpu0 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C2(200@148 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpitz0 at acpi0: critical temperature is 105 degC acpitz1 at acpi0: critical temperature is 105 degC acpicmos0 at acpi0 "INT3F0D" at acpi0 not configured acpibtn0 at acpi0: PWRB "PNP0C14" at acpi0 not configured acpivideo0 at acpi0: GFX0 acpivout0 at acpivideo0: DD1F cpu0: Enhanced SpeedStep 3392 MHz: speeds: 3201, 3200, 3000, 2900, 2700, 2500, 2300, 2200, 2000, 1800, 1700, 1500, 1300, 1
