* Machine very sluggish while compiling @ 2011-11-25 4:07 Ryan Johnson 2011-11-25 4:17 ` Mike ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Ryan Johnson @ 2011-11-25 4:07 UTC (permalink / raw) To: cygwin Hi all, Lately I've noticed that running make -j4 on my quad-core win7-x64 machine causes it to become sluggish or even unresponsive. For example, compiling a large package makes the mouse jumpy, delays keystrokes, adds stutter to my music, and makes task switching painfully slow (though, oddly, if I manage to switch to the mintty that runs make the machine "comes back"). The sluggishness always hits when I'm using a native windows app with the compile running in the background. This starts to sound oddly like the recently-reported issue where X was causing native windows apps to freeze [1]. I'm not seeing any fork failures, and am running BLODA-free (Windows Defender hasn't reappeared since I last uninstalled it). There's no unusual disk activity and memory utilization remains stable. I've tried running with nice, reducing the priority of 'make' from the task manager, and running make -j3 to no avail, though empirically if utilization stays at or below 2 cpu then there's no problem. I've compiled large apps (gcc, binutils, emacs, gdb, ...) off and on for several years now and never seen this behavior before. Any ideas of how I might diagnose the issue further? It's easy enough to work around, but compiles take a lot longer with only 1-2 cores instead of 4. Thanks, Ryan [1] http://cygwin.com/ml/cygwin-xfree/2011-11/msg00027.html -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling 2011-11-25 4:07 Machine very sluggish while compiling Ryan Johnson @ 2011-11-25 4:17 ` Mike 2011-11-25 7:22 ` Ryan Johnson 2011-11-25 15:48 ` Spiro Trikaliotis 2011-12-06 17:39 ` Andrew Schulman 2 siblings, 1 reply; 14+ messages in thread From: Mike @ 2011-11-25 4:17 UTC (permalink / raw) To: cygwin Hi Ryan, Ryan Johnson wrote: > Lately I've noticed that running make -j4 on my quad-core win7-x64 > machine causes it to become sluggish or even unresponsive. For example, > compiling a large package makes the mouse jumpy, delays keystrokes, adds > stutter to my music, and makes task switching painfully slow (though, > oddly, if I manage to switch to the mintty that runs make the machine > "comes back"). The sluggishness always hits when I'm using a native > windows app with the compile running in the background. This starts to > sound oddly like the recently-reported issue where X was causing native > windows apps to freeze [1]. > > I'm not seeing any fork failures, and am running BLODA-free (Windows > Defender hasn't reappeared since I last uninstalled it). There's no > unusual disk activity and memory utilization remains stable. I've tried > running with nice, reducing the priority of 'make' from the task > manager, and running make -j3 to no avail, though empirically if > utilization stays at or below 2 cpu then there's no problem. I've > compiled large apps (gcc, binutils, emacs, gdb, ...) off and on for > several years now and never seen this behavior before. > > Any ideas of how I might diagnose the issue further? It's easy enough to > work around, but compiles take a lot longer with only 1-2 cores instead > of 4. I've seen problems like this caused by viruses. Process Explorer might give you more detailed info: http://technet.microsoft.com/en-au/sysinternals/bb896653 Perhaps you are using a different version of bash or other shell? Some versions have been known to bog down the system as you describe. Search for bash slow might yield some clues: http://cygwin.com/ml/cygwin/ -- Regards, Mike -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling 2011-11-25 4:17 ` Mike @ 2011-11-25 7:22 ` Ryan Johnson 0 siblings, 0 replies; 14+ messages in thread From: Ryan Johnson @ 2011-11-25 7:22 UTC (permalink / raw) To: cygwin On 24/11/2011 11:06 PM, Mike wrote: > Hi Ryan, > > Ryan Johnson wrote: >> Lately I've noticed that running make -j4 on my quad-core win7-x64 >> machine causes it to become sluggish or even unresponsive. For >> example, compiling a large package makes the mouse jumpy, delays >> keystrokes, adds stutter to my music, and makes task switching >> painfully slow (though, oddly, if I manage to switch to the mintty >> that runs make the machine "comes back"). The sluggishness always >> hits when I'm using a native windows app with the compile running in >> the background. This starts to sound oddly like the recently-reported >> issue where X was causing native windows apps to freeze [1]. >> >> I'm not seeing any fork failures, and am running BLODA-free (Windows >> Defender hasn't reappeared since I last uninstalled it). There's no >> unusual disk activity and memory utilization remains stable. I've >> tried running with nice, reducing the priority of 'make' from the >> task manager, and running make -j3 to no avail, though empirically if >> utilization stays at or below 2 cpu then there's no problem. I've >> compiled large apps (gcc, binutils, emacs, gdb, ...) off and on for >> several years now and never seen this behavior before. >> >> Any ideas of how I might diagnose the issue further? It's easy enough >> to work around, but compiles take a lot longer with only 1-2 cores >> instead of 4. > > I've seen problems like this caused by viruses. Process Explorer might > give you more detailed info: > http://technet.microsoft.com/en-au/sysinternals/bb896653 I've used Process Explorer several times in the past, but it's not immediately obvious to me what I should be using it to look for. Suspicious dlls? I keep my machine patched, regularly check my process list for suspicious/unfamiliar entries, and have not had a virus in roughly 8 years (and that one was thanks to my sister in-law borrowing the machine). I can't rule out a rootkit infection, but PE wouldn't be any help there anyway. > Perhaps you are using a different version of bash or other shell? Some > versions have been known to bog down the system as you describe. > Search for bash slow might yield some clues: > http://cygwin.com/ml/cygwin/ Latest version of cygwin's bash, bash-completions package is not installed. Also, make+compilation seems to proceed at normal speed the whole time... it's everybody else that suffers. BTW, thanks for the ideas, they're definitely solid sanity checks. Regards, Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling 2011-11-25 4:07 Machine very sluggish while compiling Ryan Johnson 2011-11-25 4:17 ` Mike @ 2011-11-25 15:48 ` Spiro Trikaliotis 2011-12-04 7:55 ` Ryan Johnson 2011-12-06 17:39 ` Andrew Schulman 2 siblings, 1 reply; 14+ messages in thread From: Spiro Trikaliotis @ 2011-11-25 15:48 UTC (permalink / raw) To: cygwin Hello, * On Thu, Nov 24, 2011 at 07:59:58PM -0500 Ryan Johnson wrote: > Lately I've noticed that running make -j4 on my quad-core win7-x64 > machine causes it to become sluggish or even unresponsive. I have seen very similar effects on my Win7-64 box. I can force the problem here just be running "ccrypt", though, I do not need to use "make -j4". I assume it has to do with the Windows 64 bit problems of Cygwin (search the ML archives for that). For me, this is the first machine since years where I do not use Cygwin because of this issue. Best regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling 2011-11-25 15:48 ` Spiro Trikaliotis @ 2011-12-04 7:55 ` Ryan Johnson 2011-12-04 10:07 ` Corinna Vinschen 2011-12-04 19:29 ` Christopher Faylor 0 siblings, 2 replies; 14+ messages in thread From: Ryan Johnson @ 2011-12-04 7:55 UTC (permalink / raw) To: cygwin On 25/11/2011 10:47 AM, Spiro Trikaliotis wrote: > Hello, > > * On Thu, Nov 24, 2011 at 07:59:58PM -0500 Ryan Johnson wrote: > >> Lately I've noticed that running make -j4 on my quad-core win7-x64 >> machine causes it to become sluggish or even unresponsive. > I have seen very similar effects on my Win7-64 box. I can force the > problem here just be running "ccrypt", though, I do not need to use "make > -j4". > > I assume it has to do with the Windows 64 bit problems of Cygwin (search > the ML archives for that). > > For me, this is the first machine since years where I do not use Cygwin > because of this issue. Update: I hit the problem again, this time running python, and the problem is repeatable with the native 64-bit windows python interpreter. It looks like cygwin doesn't cause the problem, but rather my high-cpu tasks tend to run under cygwin. Honestly, I wouldn't expect cygwin to be the cause, given that it's a user space only piece of software! Now what other entity could be the cause, I haven't a clue... process explorer doesn't show anything. Maybe that's because it's frozen along with the rest of the world during these episodes; right as it comes back I see context switch deltas above 100k for the interrupt/DPC module, which suggests I've got a wonky driver somewhere. Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling 2011-12-04 7:55 ` Ryan Johnson @ 2011-12-04 10:07 ` Corinna Vinschen 2011-12-05 22:25 ` Ken Brown 2011-12-08 11:18 ` Robert Miles 2011-12-04 19:29 ` Christopher Faylor 1 sibling, 2 replies; 14+ messages in thread From: Corinna Vinschen @ 2011-12-04 10:07 UTC (permalink / raw) To: cygwin On Dec 4 02:55, Ryan Johnson wrote: > On 25/11/2011 10:47 AM, Spiro Trikaliotis wrote: > >Hello, > > > >* On Thu, Nov 24, 2011 at 07:59:58PM -0500 Ryan Johnson wrote: > > > >>Lately I've noticed that running make -j4 on my quad-core win7-x64 > >>machine causes it to become sluggish or even unresponsive. > >I have seen very similar effects on my Win7-64 box. I can force the > >problem here just be running "ccrypt", though, I do not need to use "make > >-j4". > > > >I assume it has to do with the Windows 64 bit problems of Cygwin (search > >the ML archives for that). > > > >For me, this is the first machine since years where I do not use Cygwin > >because of this issue. > Update: I hit the problem again, this time running python, and the > problem is repeatable with the native 64-bit windows python > interpreter. It looks like cygwin doesn't cause the problem, but > rather my high-cpu tasks tend to run under cygwin. Honestly, I > wouldn't expect cygwin to be the cause, given that it's a user space > only piece of software! > > Now what other entity could be the cause, I haven't a clue... > process explorer doesn't show anything. Maybe that's because it's > frozen along with the rest of the world during these episodes; right > as it comes back I see context switch deltas above 100k for the > interrupt/DPC module, which suggests I've got a wonky driver > somewhere. Here's another observation: Since Friday I'm testing a script which runs in a `while true; do done' loop. Nothing serious, just a bit of environment variable setting, calling find in an empty directory tree, grep, sed, the usual. It's running in mintty on a W7 64 bit machine. When starting to run the script, the CPU load on the dual core machine is about 70%. After a while, let's say an hour, the CPU load is 100%. Task Manager shows that one of the svchost.exe processes is grabing a lot of memory and a lot of CPU. Stop the script and the svchost still takes mem and about 50% CPU time, which means, one of the cores is solely busy to server this svchost process. Exit mintty and this svchost drops to 0% CPU and the memory usage goes down a lot. The svchost in question is the one running the following services: Windows Audio Endpoint Builder Offline Files Network Conections Program Compatibility Assistent Service Superfetch Distributed Link Tracking Client Remote Desktop Service UserMode Port Redirector Desktop Windows Manager Session Manager WLAN AutoConfig Windows Driver Foundation - User-mode Driver Framework After some testing it turned out that the culprit is the "Program Compatibility Assistent Service" service. If I stop this service, the svchost in question behaves harmless. Superfetch is no saint either in terms of memory usage, but it has by far not the influence and sticks to about 3% CPU usage after the PCA service has been stopped. Another way to fix this problem is to run the script in a Windows console window, so it's something to do with mintty. I have not the faintest idea why the PCA service thinks it has to "help" mintty along. I'm starting it from a desktop shortcut which has no compatibility mode set. Anyway, stoppping the PCA service and setting its start mode to "Manual" does the trick for me. While I was at it I also disabled Superfetch, which drops the memory usage of this svchost to a fraction of what it used before, and the CPU usage to 0%, and I don't see any performance difference. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling 2011-12-04 10:07 ` Corinna Vinschen @ 2011-12-05 22:25 ` Ken Brown 2011-12-06 10:39 ` Corinna Vinschen 2011-12-08 11:18 ` Robert Miles 1 sibling, 1 reply; 14+ messages in thread From: Ken Brown @ 2011-12-05 22:25 UTC (permalink / raw) To: cygwin On 12/4/2011 5:06 AM, Corinna Vinschen wrote: > Anyway, stoppping the PCA service and setting its start mode to "Manual" > does the trick for me. It does the trick for me too. For a long time I've been unable to build emacs using cygport's default for parallel make (-j5 because I have 4 cores). When I did this, I would either have the computer freeze (and I would have to shut it down with the power button) or else I would get a BSOD. Since stopping PCA, the problem seems to be gone. Ken -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling 2011-12-05 22:25 ` Ken Brown @ 2011-12-06 10:39 ` Corinna Vinschen 0 siblings, 0 replies; 14+ messages in thread From: Corinna Vinschen @ 2011-12-06 10:39 UTC (permalink / raw) To: cygwin On Dec 5 17:25, Ken Brown wrote: > On 12/4/2011 5:06 AM, Corinna Vinschen wrote: > >Anyway, stoppping the PCA service and setting its start mode to "Manual" > >does the trick for me. > > It does the trick for me too. For a long time I've been unable to > build emacs using cygport's default for parallel make (-j5 because I > have 4 cores). When I did this, I would either have the computer > freeze (and I would have to shut it down with the power button) or > else I would get a BSOD. > > Since stopping PCA, the problem seems to be gone. In the meantime I found another way how to avoid this problem. Here's an excerpt from the MSDN man page of AssignProcessToJobObject: If the process is being monitored by the Program Compatibility Assistant (PCA), it is placed into a compatibility job. Therefore, the process must be created using CREATE_BREAKAWAY_FROM_JOB before it can be placed in another job. Alternatively, you can embed an application manifest that specifies a User Account Control (UAC) level in your application and PCA will not add the process to the compatibility job. So, what I did was to change Cygwin locally to add the CREATE_BREAKAWAY_FROM_JOB flag to the CreateProcess call when execing a process. With this change, I had no problems with PCA anymore. I also tried to use an "asInvoker" side-by-side manifest for mintty, but I had no luck with it. PCA still wasted memory and CPU. So I'm wondering if we should simply add the CREATE_BREAKAWAY_FROM_JOB flag to our CreateProcess calls and be done with it. As far as I can see, and from what MSDN claims, there should be no problem doing that. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling 2011-12-04 10:07 ` Corinna Vinschen 2011-12-05 22:25 ` Ken Brown @ 2011-12-08 11:18 ` Robert Miles 2011-12-08 13:15 ` Ryan Johnson 1 sibling, 1 reply; 14+ messages in thread From: Robert Miles @ 2011-12-08 11:18 UTC (permalink / raw) To: cygwin On 12/4/2011 4:06 AM, Corinna Vinschen wrote: > On Dec 4 02:55, Ryan Johnson wrote: >> On 25/11/2011 10:47 AM, Spiro Trikaliotis wrote: >>> Hello, >>> >>> * On Thu, Nov 24, 2011 at 07:59:58PM -0500 Ryan Johnson wrote: >>> >>>> Lately I've noticed that running make -j4 on my quad-core win7-x64 >>>> machine causes it to become sluggish or even unresponsive. >>> I have seen very similar effects on my Win7-64 box. I can force the >>> problem here just be running "ccrypt", though, I do not need to use "make >>> -j4". >>> >>> I assume it has to do with the Windows 64 bit problems of Cygwin (search >>> the ML archives for that). >>> >>> For me, this is the first machine since years where I do not use Cygwin >>> because of this issue. >> Update: I hit the problem again, this time running python, and the >> problem is repeatable with the native 64-bit windows python >> interpreter. It looks like cygwin doesn't cause the problem, but >> rather my high-cpu tasks tend to run under cygwin. Honestly, I >> wouldn't expect cygwin to be the cause, given that it's a user space >> only piece of software! >> >> Now what other entity could be the cause, I haven't a clue... >> process explorer doesn't show anything. Maybe that's because it's >> frozen along with the rest of the world during these episodes; right >> as it comes back I see context switch deltas above 100k for the >> interrupt/DPC module, which suggests I've got a wonky driver >> somewhere. > Here's another observation: > > Since Friday I'm testing a script which runs in a `while true; do done' > loop. Nothing serious, just a bit of environment variable setting, > calling find in an empty directory tree, grep, sed, the usual. > > It's running in mintty on a W7 64 bit machine. When starting to run the > script, the CPU load on the dual core machine is about 70%. After a > while, let's say an hour, the CPU load is 100%. Task Manager shows that > one of the svchost.exe processes is grabing a lot of memory and a lot of > CPU. Stop the script and the svchost still takes mem and about 50% CPU > time, which means, one of the cores is solely busy to server this > svchost process. Exit mintty and this svchost drops to 0% CPU and the > memory usage goes down a lot. > > The svchost in question is the one running the following services: > > Windows Audio Endpoint Builder > Offline Files > Network Conections > Program Compatibility Assistent Service > Superfetch > Distributed Link Tracking Client > Remote Desktop Service UserMode Port Redirector > Desktop Windows Manager Session Manager > WLAN AutoConfig > Windows Driver Foundation - User-mode Driver Framework > > After some testing it turned out that the culprit is the "Program > Compatibility Assistent Service" service. If I stop this service, the > svchost in question behaves harmless. Superfetch is no saint either in > terms of memory usage, but it has by far not the influence and sticks to > about 3% CPU usage after the PCA service has been stopped. > > Another way to fix this problem is to run the script in a Windows console > window, so it's something to do with mintty. > I have not the faintest idea why the PCA service thinks it has to "help" > mintty along. I'm starting it from a desktop shortcut which has no > compatibility mode set. > > Anyway, stoppping the PCA service and setting its start mode to "Manual" > does the trick for me. While I was at it I also disabled Superfetch, > which drops the memory usage of this svchost to a fraction of what it > used before, and the CPU usage to 0%, and I don't see any performance > difference. > > > Corinna > Are you aware that the Superfetch service deliberately tries to use most of the memory not otherwise in use as a cache for the most frequently accessed disk files, in order to speed up accesses to those files? I've found it rather slow to release this cache memory when some other program needs it, though. Robert Miles -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling 2011-12-08 11:18 ` Robert Miles @ 2011-12-08 13:15 ` Ryan Johnson 0 siblings, 0 replies; 14+ messages in thread From: Ryan Johnson @ 2011-12-08 13:15 UTC (permalink / raw) To: cygwin On 08/12/2011 6:18 AM, Robert Miles wrote: > On 12/4/2011 4:06 AM, Corinna Vinschen wrote: >> Anyway, stoppping the PCA service and setting its start mode to "Manual" >> does the trick for me. While I was at it I also disabled Superfetch, >> which drops the memory usage of this svchost to a fraction of what it >> used before, and the CPU usage to 0%, and I don't see any performance >> difference. > Are you aware that the Superfetch service deliberately tries to use > most of the > memory not otherwise in use as a cache for the most frequently > accessed disk > files, in order to speed up accesses to those files? I've found it > rather slow to > release this cache memory when some other program needs it, though. In my experience Superfetch does a phenomenally bad job of predicting which files I (or my wife) actually plan to use. The machine is sluggish not (just) because the memory is uselessly tied up, but because the disk is constantly busy fetching data that will never be used and penalizes access to the data I actually do need. The memory wastage just compounds the problem by contributing additional swapping on top of all this other extra disk activity. Both computers at my house saw *significant increases* in performance and responsiveness when I disabled Superfetch a few months ago. Ryan -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling 2011-12-04 7:55 ` Ryan Johnson 2011-12-04 10:07 ` Corinna Vinschen @ 2011-12-04 19:29 ` Christopher Faylor [not found] ` <4EDBD5A5.2000707@cs.utoronto.ca> 1 sibling, 1 reply; 14+ messages in thread From: Christopher Faylor @ 2011-12-04 19:29 UTC (permalink / raw) To: cygwin On Sun, Dec 04, 2011 at 02:55:13AM -0500, Ryan Johnson wrote: >On 25/11/2011 10:47 AM, Spiro Trikaliotis wrote: >> Hello, >> >> * On Thu, Nov 24, 2011 at 07:59:58PM -0500 Ryan Johnson wrote: >> >>> Lately I've noticed that running make -j4 on my quad-core win7-x64 >>> machine causes it to become sluggish or even unresponsive. >> I have seen very similar effects on my Win7-64 box. I can force the >> problem here just be running "ccrypt", though, I do not need to use "make >> -j4". >> >> I assume it has to do with the Windows 64 bit problems of Cygwin (search >> the ML archives for that). >> >> For me, this is the first machine since years where I do not use Cygwin >> because of this issue. >Update: I hit the problem again, this time running python, and the >problem is repeatable with the native 64-bit windows python interpreter. >It looks like cygwin doesn't cause the problem, but rather my high-cpu >tasks tend to run under cygwin. Honestly, I wouldn't expect cygwin to be >the cause, given that it's a user space only piece of software! > >Now what other entity could be the cause, I haven't a clue... process >explorer doesn't show anything. Maybe that's because it's frozen along >with the rest of the world during these episodes; right as it comes back >I see context switch deltas above 100k for the interrupt/DPC module, >which suggests I've got a wonky driver somewhere. Out of curiousity, is the current snapshot any better? I just found a case where Cygwin could essentially enter a tight loop while waiting for I/O. It would seem to be working correctly but it would use a lot of CPU time. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
[parent not found: <4EDBD5A5.2000707@cs.utoronto.ca>]
* Re: Machine very sluggish while compiling [not found] ` <4EDBD5A5.2000707@cs.utoronto.ca> @ 2011-12-04 20:23 ` Ryan Johnson 0 siblings, 0 replies; 14+ messages in thread From: Ryan Johnson @ 2011-12-04 20:23 UTC (permalink / raw) To: cygwin Trying again without the verboten 80kB PNG attachment... On 04/12/2011 3:18 PM, Ryan Johnson wrote: > On 04/12/2011 2:29 PM, Christopher Faylor wrote: >> On Sun, Dec 04, 2011 at 02:55:13AM -0500, Ryan Johnson wrote: >>> On 25/11/2011 10:47 AM, Spiro Trikaliotis wrote: >>>> Hello, >>>> >>>> * On Thu, Nov 24, 2011 at 07:59:58PM -0500 Ryan Johnson wrote: >>>> >>>>> Lately I've noticed that running make -j4 on my quad-core win7-x64 >>>>> machine causes it to become sluggish or even unresponsive. >>>> I have seen very similar effects on my Win7-64 box. I can force the >>>> problem here just be running "ccrypt", though, I do not need to use >>>> "make >>>> -j4". >>>> >>>> I assume it has to do with the Windows 64 bit problems of Cygwin >>>> (search >>>> the ML archives for that). >>>> >>>> For me, this is the first machine since years where I do not use >>>> Cygwin >>>> because of this issue. >>> Update: I hit the problem again, this time running python, and the >>> problem is repeatable with the native 64-bit windows python >>> interpreter. >>> It looks like cygwin doesn't cause the problem, but rather my high-cpu >>> tasks tend to run under cygwin. Honestly, I wouldn't expect cygwin >>> to be >>> the cause, given that it's a user space only piece of software! >>> >>> Now what other entity could be the cause, I haven't a clue... process >>> explorer doesn't show anything. Maybe that's because it's frozen along >>> with the rest of the world during these episodes; right as it comes >>> back >>> I see context switch deltas above 100k for the interrupt/DPC module, >>> which suggests I've got a wonky driver somewhere. >> Out of curiousity, is the current snapshot any better? I just found a >> case where Cygwin could essentially enter a tight loop while waiting for >> I/O. It would seem to be working correctly but it would use a lot of >> CPU time. > Again, I'm no longer convinced that this is Cygwin's fault -- it just > so happened that all my CPU-intensive tasks were cygwin apps. I'm > starting to notice a pattern, though: with three cpu-bound apps > running, my laptop's fan comes on every two minutes (precisely). About > five seconds later, the frequency drops by 50% and cpu util promptly > saturates as a result. After one minute of this, the frequency hikes > back up and we're good... until the cycle repeats a minute later (see > the attached snippet of screen shot). > > So, the questions are how come: > - power/heat management isn't giving the fan a chance to work before > clamping the clock frequency? > - scheduler can't cope better with 100% cpu util? > > While I'm glad to take any expert advice people might have, I think we > can close this thread as far as Cygwin is concerned. > > BTW, Corinna's advice to disable PCA did help somewhat (and > Firefox/Thunderbird util dropped as well as a bonus). However, it's > probably only a treatment of symptoms in my case; I already had > superfetch disabled. > > Thanks, > Ryan > -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling 2011-11-25 4:07 Machine very sluggish while compiling Ryan Johnson 2011-11-25 4:17 ` Mike 2011-11-25 15:48 ` Spiro Trikaliotis @ 2011-12-06 17:39 ` Andrew Schulman 2011-12-07 5:23 ` Mike 2 siblings, 1 reply; 14+ messages in thread From: Andrew Schulman @ 2011-12-06 17:39 UTC (permalink / raw) To: cygwin > Lately I've noticed that running make -j4 on my quad-core win7-x64 > machine causes it to become sluggish or even unresponsive. For example, > compiling a large package makes the mouse jumpy, delays keystrokes, adds > stutter to my music, and makes task switching painfully slow (though, > oddly, if I manage to switch to the mintty that runs make the machine > "comes back"). The sluggishness always hits when I'm using a native > windows app with the compile running in the background. This starts to > sound oddly like the recently-reported issue where X was causing native > windows apps to freeze [1]. I'm glad to hear it's not just me. I've been struggling with this for a few months, on my WinXP SP3 (32-bit, dual-core) host. I avoid compiling on it, because after a few minutes CPU goes to 100% even after I exit all Cygwin processes, and once that happens the only solution is to reboot... which I usually do with the reset button, because by that point everything is so slow that even rebooting takes 15 minutes. There's no PCA or Superfetch service on my host. I'll try shutting down other services to see if that helps. Andrew. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Machine very sluggish while compiling 2011-12-06 17:39 ` Andrew Schulman @ 2011-12-07 5:23 ` Mike 0 siblings, 0 replies; 14+ messages in thread From: Mike @ 2011-12-07 5:23 UTC (permalink / raw) To: cygwin Hi Andrew, Andrew Schulman wrote: >> Lately I've noticed that running make -j4 on my quad-core win7-x64 >> machine causes it to become sluggish or even unresponsive. For example, >> compiling a large package makes the mouse jumpy, delays keystrokes, adds >> stutter to my music, and makes task switching painfully slow (though, >> oddly, if I manage to switch to the mintty that runs make the machine >> "comes back"). The sluggishness always hits when I'm using a native >> windows app with the compile running in the background. This starts to >> sound oddly like the recently-reported issue where X was causing native >> windows apps to freeze [1]. > > I'm glad to hear it's not just me. I've been struggling with this for a few > months, on my WinXP SP3 (32-bit, dual-core) host. I avoid compiling on it, > because after a few minutes CPU goes to 100% even after I exit all Cygwin > processes, and once that happens the only solution is to reboot... which I > usually do with the reset button, because by that point everything is so slow > that even rebooting takes 15 minutes. > > There's no PCA or Superfetch service on my host. I'll try shutting down other > services to see if that helps. Look for the Application Compatibility Toolkit (ACT) as described at: http://support.microsoft.com/kb/294895 removing it helps some computers a lot. Another program that causes problems on some computers is the MS Office 2010 Click-to-Run system. It's usually associated with the trial version. With this system, software is downloaded and installed dynamically as it is used. Hangs and slowdowns when logging off or rebooting were noted. Removing this will help. If MSO is needed, the DVD version can be installed. Also removing .NET and re-installing it can help some computers. -- Regards, Mike -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2011-12-08 13:15 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-11-25 4:07 Machine very sluggish while compiling Ryan Johnson 2011-11-25 4:17 ` Mike 2011-11-25 7:22 ` Ryan Johnson 2011-11-25 15:48 ` Spiro Trikaliotis 2011-12-04 7:55 ` Ryan Johnson 2011-12-04 10:07 ` Corinna Vinschen 2011-12-05 22:25 ` Ken Brown 2011-12-06 10:39 ` Corinna Vinschen 2011-12-08 11:18 ` Robert Miles 2011-12-08 13:15 ` Ryan Johnson 2011-12-04 19:29 ` Christopher Faylor [not found] ` <4EDBD5A5.2000707@cs.utoronto.ca> 2011-12-04 20:23 ` Ryan Johnson 2011-12-06 17:39 ` Andrew Schulman 2011-12-07 5:23 ` Mike
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).