Machine very sluggish while compiling

Machine very sluggish while compiling

[Ryan Johnson]

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

Re: Machine very sluggish while compiling

[Mike]

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

Re: Machine very sluggish while compiling

[Ryan Johnson]

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

Re: Machine very sluggish while compiling

[Spiro Trikaliotis]

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

Re: Machine very sluggish while compiling

[Ryan Johnson]

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

Re: Machine very sluggish while compiling

[Corinna Vinschen]

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

Re: Machine very sluggish while compiling

[Ken Brown]

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

Re: Machine very sluggish while compiling

[Corinna Vinschen]

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

Re: Machine very sluggish while compiling

[Robert Miles]

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

Re: Machine very sluggish while compiling

[Ryan Johnson]

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

Re: Machine very sluggish while compiling

[Christopher Faylor]

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

Re: Machine very sluggish while compiling

[Ryan Johnson]

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

Re: Machine very sluggish while compiling

[Andrew Schulman]

> 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

Re: Machine very sluggish while compiling

[Mike]

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