Hello all. I have noticed some discrpancies in the Linux VM as opposed to the Win32 VM. Here is a summary (was on squeak-dev): ---------------------------- Hi all. Does anybody know why, on the Linux VM (3.9.8), short Delays (<500ms) wait for significantly longer than under Windows (3.10.4)? As an example for the average time spent waiting when requesting a 10ms wait: ((1 to: 100) collect: [:i | Time millisecondsToRun: [(Delay forMilliseconds: 10) wait]]) sum / 100.0 This yields (on my machine) 10.35 for Windows and 43.48 for Linux. For a 100ms wait: 100.5 (Windows) and 131.39 (Linux). For a 1000ms wait: 1000.36 (Windows) and 1013.16 (Linux). There seems to be a fixed overhead per call that is significantly larger under Linux. Any thoughts would be appreciated. ------------------------------ Even with a loadavg (via uptime) of around 0.01 it was still around 44ms (for a 10ms delay) for me. Found the culprit though... In sqUnixMain.c sqInt ioRelinquishProcessorForMicroseconds(sqInt us) { int now; dpy->ioRelinquishProcessorForMicroseconds(us); now= ioLowResMSecs(); if (now - lastInterruptCheck > (1000/25)) /* avoid thrashing intr checks from 1ms loop in idle proc */ { setInterruptCheckCounter(-1000); /* ensure timely poll for semaphore activity */ lastInterruptCheck= now; } return 0; } Note the (1000/25) which equals 40ms, around the same as the latency. Called from #relinquishProcessorForMicroseconds: in ProcessorScheduler, By the the idle process with a 1000 microsecond value. This reliquishes the processor for the 1000 microseconds then doesn't check for interrupts (including Pending delay semaphores) until at least 40ms have passed. Perhaps this could be made into a VM parameter? |
Gary Chambers wrote: > if (now - lastInterruptCheck > (1000/25)) /* avoid thrashing intr > checks from 1ms loop in idle proc */ I don't think that in this day and age doing a 1000 interrupt checks/sec can be considered "thrashing" ;-) I'd just remove it and get the 1ms time resolution back. Cheers, - Andreas |
On Jun 13, 2007, at 10:25 AM, Andreas Raab wrote: > Gary Chambers wrote: >> if (now - lastInterruptCheck > (1000/25)) /* avoid thrashing intr >> checks from 1ms loop in idle proc */ > > I don't think that in this day and age doing a 1000 interrupt > checks/sec can be considered "thrashing" ;-) I'd just remove it and > get the 1ms time resolution back. The other thing you're likely to get back is 100% CPU usage. But by all means, try it. Cheers, Ian |
Ian Piumarta wrote: > > On Jun 13, 2007, at 10:25 AM, Andreas Raab wrote: > >> Gary Chambers wrote: >>> if (now - lastInterruptCheck > (1000/25)) /* avoid thrashing intr >>> checks from 1ms loop in idle proc */ >> >> I don't think that in this day and age doing a 1000 interrupt >> checks/sec can be considered "thrashing" ;-) I'd just remove it and >> get the 1ms time resolution back. > > The other thing you're likely to get back is 100% CPU usage. But by all > means, try it. Why would that be? Is there any intrinsic limitation that I'm unaware of? Cheers, - Andreas |
On Jun 14, 2007, at 8:26 AM, Andreas Raab wrote: > Why would that be? Is there any intrinsic limitation that I'm > unaware of? The Linux kernel refuses (or did the last time I checked) to go to sleep in select timeout for < a timeslice; it just returns immediately. Cheers, Ian |
In reply to this post by Ian Piumarta
I'll try it. To be fair, for our application 100% cpu might not be a bad thing ;-) Next week when I'm in the office I'll give it a go. Perhaps tweaking the idle process will free some cpu if a problem. The ioRelinquishProcessorForMicroseconds(us) will still get called. More important for the app is timely responses to delay semaphores. Thanks for the responses! -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Ian Piumarta Sent: 14 June 2007 4:20 pm To: Squeak Virtual Machine Development Discussion Subject: Re: [Vm-dev] Linux VM and Delay. On Jun 13, 2007, at 10:25 AM, Andreas Raab wrote: > Gary Chambers wrote: >> if (now - lastInterruptCheck > (1000/25)) /* avoid thrashing intr >> checks from 1ms loop in idle proc */ > > I don't think that in this day and age doing a 1000 interrupt > checks/sec can be considered "thrashing" ;-) I'd just remove it and > get the 1ms time resolution back. The other thing you're likely to get back is 100% CPU usage. But by all means, try it. Cheers, Ian |
In reply to this post by Ian Piumarta
> The Linux kernel refuses (or did the last time I checked) to go to > sleep in select timeout for < a timeslice; it just returns > immediately. Flow has its own "relinquish physical processor" primitive, which uses pthread_cond_timedwait(). Works great: proper timing, no undesired CPU activity. Same code works on MacOSX, too. -C -- Craig Latta improvisational musical informaticist www.netjam.org Smalltalkers do: [:it | All with: Class, (And love: it)] |
In reply to this post by Gary Chambers-4
Tried with a modded VM, just changed the 1000/25 check to 1. Get better-than-win32 semaphore responses and no CPU runaway. Do you think it would be best to incorporate this change into the main VM? (Running Gentoo 2.6.20 kernel) -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Gary Chambers Sent: 14 June 2007 9:02 pm To: 'Squeak Virtual Machine Development Discussion' Subject: RE: [Vm-dev] Linux VM and Delay. I'll try it. To be fair, for our application 100% cpu might not be a bad thing ;-) Next week when I'm in the office I'll give it a go. Perhaps tweaking the idle process will free some cpu if a problem. The ioRelinquishProcessorForMicroseconds(us) will still get called. More important for the app is timely responses to delay semaphores. Thanks for the responses! -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Ian Piumarta Sent: 14 June 2007 4:20 pm To: Squeak Virtual Machine Development Discussion Subject: Re: [Vm-dev] Linux VM and Delay. On Jun 13, 2007, at 10:25 AM, Andreas Raab wrote: > Gary Chambers wrote: >> if (now - lastInterruptCheck > (1000/25)) /* avoid thrashing intr >> checks from 1ms loop in idle proc */ > > I don't think that in this day and age doing a 1000 interrupt > checks/sec can be considered "thrashing" ;-) I'd just remove it and > get the 1ms time resolution back. The other thing you're likely to get back is 100% CPU usage. But by all means, try it. Cheers, Ian |
Free forum by Nabble | Edit this page |