Linux VM and Delay.

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Linux VM and Delay.

Gary Chambers-4

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?

Reply | Threaded
Open this post in threaded view
|

Re: Linux VM and Delay.

Andreas.Raab
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Linux VM and Delay.

Ian Piumarta
 
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



Reply | Threaded
Open this post in threaded view
|

Re: Linux VM and Delay.

Andreas.Raab
 
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
Reply | Threaded
Open this post in threaded view
|

Re: Linux VM and Delay.

Ian Piumarta
 
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

Reply | Threaded
Open this post in threaded view
|

RE: Linux VM and Delay.

Gary Chambers-4
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



Reply | Threaded
Open this post in threaded view
|

Re: Linux VM and Delay.

ccrraaiigg
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)]


Reply | Threaded
Open this post in threaded view
|

RE: Linux VM and Delay.

Gary Chambers-4
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