Date: Sun, 4 Dec 2011 14:29:17 -0500
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Machine very sluggish while compiling
Message-ID: <20111204192917.GB21203@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <4ECEE88E DOT 5050307 AT cs DOT utoronto DOT ca> <20111125154751 DOT GP28395 AT trikaliotis DOT net> <4EDB2761 DOT 6040508 AT cs DOT utoronto DOT ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4EDB2761.6040508@cs.utoronto.ca>
User-Agent: Mutt/1.5.20 (2009-06-14)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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