Re: More about slowing down the machine

["Gary R. Van Sickle" <g dot r dot vansickle at worldnet dot att dot net>]

> ----- Original Message -----
> From: "David A. Cobb" <superbiskit@home.com>
> To: "Cygwin Library General Discussion" <cygwin@cygwin.com>
> Sent: Saturday, October 13, 2001 8:21 AM
> Subject: More about slowing down the machine
>
>
> > Win98se (4.10.2222) en_US; Cygwin1.dll 1.3.4s (2001-10-11 [I think]).
> >
> >
> > To repeat, when the anomaly is happening Windows is unable to track
> the
> > mouse and the Windows clock is being updated at about 1/4 speed.  The
> > build started at 18:30 - and the clock was right - and ended at 21:00
> > with the clock reading 19:05.  Somehow the message queue(s) aren't
> being
> > checked and "pre-emptive scheduling" isn't very much so.
>

I just want to chime in here and say that David's not crazy (well, no
crazier than I am ;-)): I've been seeing pretty much the same things he is
on WhyME for quite a while now (no such problems on Why2K though AFAICT).
What I see though is that there is no problem initially, but the more I use
Cygwin the "slower" the system gets until it's completely unusable (say e.g.
maybe after three or four winsup builds).  By "slower" I mean basically the
same thing David does: mouse tracking goes to hell, sound playback in other
apps starts blocking, etc.  I haven't noticed the time thing, but I haven't
looked either.

Worst though is that the problem does *not* go away even if all Cygwin apps
are exited or killed with ProcessExplorer etc.  No Cygwin processes will
show up in ProcessExplorer, but the problem does not go away.

> As has already been said, a user mode program shouldn't be able to cause
> this...

Well, the Cygwin DLL is no ordinary user-mode program though (fork
immediately comes to mind).

> mind you, you are on win16 :}.
>

Right, which is of course why any potential problems like this can "leak"
out into the entire system and hose it.  But the problem could very well
exist on Why2K too and e.g. be slowing down builds etc, and just not be as
visible since there's no permanent effect on the system as a whole.

> Hmm, usual cause for that is a high interrupt count - does the h/w
> interrupt rate change during make?.
>

How can one tell?

I would think that a high-priority process stuck somewhere could do the same
thing though.  And exceptions.cc/signal_exit() does this:

(void) SetThreadPriority (GetCurrentThread (),
THREAD_PRIORITY_TIME_CRITICAL);

I'm trying to come up with some scheme to catch any processes which get here
but never actually terminate.  Probably a wild goose chase....

> Another thing is 16 bit legacy drivers floating around.
>

AFAIK I have none.

> Also, some thing\s to try:
> * nice make (note: I suspect that this has a bug at the moment, in that
> fork()/exec() IIRC doesn't set the priority on the new process - which
> will mean that only the parent is set. You might want to grab a renice
> for windows, and see if dropping the make2 process priority alters
> things.

Worth a try, thanks for the tip.

> * use process explorer from sysinternals.com to see if an excessive
> number of handles are open by make2. AND - if you are looking for a
> spinlock, all the win32 sync objects involve handles - so look for a
> handle in make2 that is open in the child - or is the child.

I don't see any problems there.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/