This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: More about slowing down the machine


> -----Original Message-----
> From: Gary R. Van Sickle [mailto:g.r.vansickle@worldnet.att.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.
> >
> 
> apps starts blocking, etc.  I haven't noticed the time thing, 
> but I haven't looked either.

Sure, never thought David was crazy :}.

> 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.

Ah! I'll get you to chase some pointers at MS Technet
(support.microsoft.com) then. Look for things like "16-bit resource
leak", "Handle leak" etc. Specifically: look for problems where the
solution involves a reboot.

> > 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).

Sorry, but fork is accomplished entirely with user mode calls. The only
'privilege' needed is the ability to write into the new process's
address space, which is provided by Win32 itself.

> > 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.

That is a possibility, but if it is a message queue related issue
(unknown yet, we only know that it *affects* the queue processing) then
9x's blocking message queue for all kernel operations that enter 16 bit
code is the obvious culprit. Under NT it's not that the problem isn't
obvious, rather it is that there *is no problem*. 

That doesn't mean there isn't a problem that win2k is cleaning up for us
- I'm simply saying that there is a lot of room for "no problem at all"
in this particular case :}.
 
> > Hmm, usual cause for that is a high interrupt count - does the h/w
> > interrupt rate change during make?.
> >
> 
> How can one tell?

Under NT one grabs performance monitor, system object, interrupts/sec
counter. Under 9x you will need to research this :}. 

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

followed by terminating the process. Not really an issue unless a large
chunk of your processes are killed rather than exiting.
 
As for a high process thread doing this? Not really. To degrade the
system clock, IIRC my low level hardware correctly, you have to run for
extended periods with interrupts disabled, so that the timer interrupt
doesn't fire, _or_ you have to have so many Interrupt Service Routines's
in progress that the timer interrupt handler overlaps or reenters.

And finally, cygwin doesn't change the process class of process's unless
nice is called. (See MSDN for process Priority Class versus Thread
Priority. Basically any realtime process's thread will come ahead of any
cygwin process. And device drivers are AFAIK invariably realtime in
priority, at least for the core ISR. A deferred interrrupt handler is
where the interrupt occurs, and the data is posted in a queue, to be
processed later, and a lower priority. Cygwin could interfere with those
if the priority class of the deferred handler process is low enough.
 
> 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....

Indeed!

> > Another thing is 16 bit legacy drivers floating around.
> >
> 
> AFAIK I have none.

SystemInfo is a good place to start to check this. 

Also, you and David might like to compare notes on hardware and software
setup,
TSR's, device driver versions etc

As a last word anyone who experiences this needs to methodically step
through their system guts, using the Technet & MSDN troubleshooting
material to get hints on where to go until the *cause* is found, and
then a developer (if the user doesn't grok Cygwin source :}) can assist.
I've done a fair few of these things before, but not usually on the
developer side of the fence :}.

I'm happy to keep offering suggestions about how to accomplish this..

Rob

--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]