The manpage for priocntl says that although it is possible to change priority limit for IA (which is the Inter-Active scheduler class), for the TS (TimeSharing) and IA (InterActive) class , it says there is no guarantuee that the change will be used:

"The priorities of processes in the inter-active class can be changed in the same manner as those in the time-sharing class, though / the modified priorities continue to be adjusted /to provide good responsiveness for user interaction."

For the TS class (similar to IA) it says:

"It is not guaranteed, however, that a time-sharing process with a *higher tsupri value runs before one with a lower tsupri value*. This is because the tsupri value is just one factor used to determine the scheduling priority of a time-sharing process."

Another choice which also seems to help to get rid of the pthread_setschedparam() error or warning, is to use th FX (fixed priority) class.

So is it recommended to run the squeak process as a process in the RT (realtime) class to get rid of the warning ?

-- Sent from: http://forum.world.st/Squeak-VM-f104410.html

ok this requires further testing

also it may be possible to give the squeak executable "authorization" to issue a proc_priocntl "authorization" so that it can change the priority on Solaris (I'm not familiar with that, but it may be possible, should be investigated)

in any case I think the "ps" output shows one thread is now running at higher priority, so I'll try the test you posted

-- Sent from: http://forum.world.st/Squeak-VM-f104410.html

On 30.03.2020, at 10:27, stes stes@telenet.be wrote:

Because I have meanwhile a 64 bit version, I continue to look into this.

First of all, the 64 bit version executable seems to work excellent, the system is running very responsively, very smoothly.

I run it in RT (realtime class):

bash-4.4$ priocntl -d $$ REAL TIME PROCESSES: PID[/LWP] RTPRI TQNTM TQSIG 8514 0 1000 0 bash-4.4$ bin/squeak Squeak5.3-19431-64bit.image

There's no printf() warning when starting bin/squeak as such. So there's no "pthread_setschedparam failed" message , provided I run the process in the RT class.

The Squeak image works perfectly fine.

I have tried to copied the following code (that was posted by Eliot Miranda in this discussion thread).

I copied the following in a Transcript window:

   | proc sem |
   proc := [| n |
                  n := 0.
                  [(n := n + 1) even ifTrue:
                         [n := n - 1]] repeat] newProcess.
   sem := Semaphore new.
   [(Delay forSeconds: 1) wait.
     proc terminate.
     sem signal] forkAt: Processor userInterruptPriority.
   proc resume.
   sem wait

Then I select the above and choose from Control-d "do it" from the menu

Nothing happens. How is the above code exactly supposed to test anything, please ??

I don't quite understand the code and how it relates to the heart-beat thread.

At the UNIX level I can see there are 2 threads or LWP ( light weight processes) where one is running at a higher priority than the other.

That's expected. One is running the main interpreter/JIT, the other is a timer thread that makes sure the time info and events for the Squeak image are exact and delivered.

Glad to see it work on FreeBSD. I hadn't had much time lately, but I had investigated things while back. Also we had other people looking into FreeBSD-specific (see https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/32 for example) Thank you!

Best regards -Tobias

On 30.03.2020, at 14:56, stes stes@telenet.be wrote:

This is not on FreeBSD but on Solaris ... (a different UNIX). I see there's a different subject thread for people who try to make a FreeBSD version as well.

Sorry, I mixed those, my bad. But Solaris is also nice! Btw, which Solaris?

Best regards -Tobias

Perhaps a FreeBSD port is more difficult than a Solaris port, because my understanding is that the Solaris "port" is not so hard because Solaris was in the past well supported by Squeak.

There were Solaris ports in the past so it's just a matter of making sure it keeps working.

My understanding of the pthread_setschedparam() issue, is that although it is supported on Solaris to set the priority on IA, there's no guarantuee it has the desired effect in IA class. Theoretically it should be better in RT.

But in practice I don't see a big difference, although that I could do some "benchmark" or test.

Like the code that was posted by Eliot Miranda.

But I don't quite get the idea of that code, am I supposed to test in a Transcript window ? what should be the result in RT class versus non-RT class etc. ...

Hi

On 30.03.2020, at 19:04, stes stes@telenet.be wrote:

This is on Solaris 11.3 and Solaris 11.4. Solaris 11.4 for Intel / AMD, not for SPARC.

I don't see a SPARC version at http://squeakvm.org/unix/ so this is already long ago, that squeak was compiled on SPARC, although that the source code has some references to SPARC, so longtime ago this was available I think, it seems it existed at some point in the past.

Anyway I currently use Squeak V5 with 5.x images on Solaris 11.3 and 11.4 for Intel.

I can't remember any SPARC effort for as long as I use Squeak, either. I once tried compiling it on OpenSolaris on a SPARC machine, but thats long ago.

Best regards -Tobias

Hi Stes,

On Mar 30, 2020, at 1:27 AM, stes stes@telenet.be wrote:



Because I have meanwhile a 64 bit version, I continue to look into this.

First of all, the 64 bit version executable seems to work excellent, the system is running very responsively, very smoothly.

I run it in RT (realtime class):

bash-4.4$ priocntl -d $$ REAL TIME PROCESSES: PID[/LWP] RTPRI TQNTM TQSIG 8514 0 1000 0 bash-4.4$ bin/squeak Squeak5.3-19431-64bit.image

There's no printf() warning when starting bin/squeak as such. So there's no "pthread_setschedparam failed" message , provided I run the process in the RT class.

The Squeak image works perfectly fine.

I have tried to copied the following code (that was posted by Eliot Miranda in this discussion thread).

I copied the following in a Transcript window:

   | proc sem |
   proc := [| n |
                  n := 0.
                  [(n := n + 1) even ifTrue:
                         [n := n - 1]] repeat] newProcess.
   sem := Semaphore new.
   [(Delay forSeconds: 1) wait.
     proc terminate.
     sem signal] forkAt: Processor userInterruptPriority.
   proc resume.
   sem wait

Then I select the above and choose from Control-d "do it" from the menu

Nothing happens. How is the above code exactly supposed to test anything, please ??

The code creates one process proc that consumes all available cpu (in a single thread) but does not invoke garbage collection because all it does is loop setting n to 1 or 2. So if the heartbeat thread is not running at a higher priority then it will be prevented from running by proc shutting it out (ignoring issues of thread processor affinity and multi core, but the vm is essentially a single Smalltalk execution thread so let’s keep within that model). And if the heartbeat thread is prevented from running then the spin loop proc will not break out to check for the delay timer expiring and so proc will not stop after a second. Instead the system may lock up.

So the fact that nothing happens (in fact something does happen, the system is unresponsive for 1 second; try print it instead of doit, or surround the example in [ ... ] timeToRun) shows that the heartbeat thread is working correctly.

I don't quite understand the code and how it relates to the heart-beat thread.

At the UNIX level I can see there are 2 threads or LWP ( light weight processes) where one is running at a higher priority than the other.

-- Sent from: http://forum.world.st/Squeak-VM-f104410.html

Hi Stes,

I answered this at length here earlier today. Just forwarded the message to you.

_,,,^..^,,,_ (phone)

On Apr 1, 2020, at 9:59 AM, stes stes@telenet.be wrote:



| proc sem |
   proc := [| n |
                  n := 0.
                  [(n := n + 1) even ifTrue:
                         [n := n - 1]] repeat] newProcess.
   sem := Semaphore new.
   [(Delay forSeconds: 1) wait.
     proc terminate.
     sem signal] forkAt: Processor userInterruptPriority.
   proc resume.
   sem wait

If I select the above and choose "print it" it prints:

a Semaphore()

If put [] around it and print it , it prints 1002

I'm sorry this is a beginner's question but I don't quite see what the result of the program should be, and whether the answer is correct.

I ran the above code in the RT (real time) class

bash-4.4$ priocntl -d $$ REAL TIME PROCESSES: PID[/LWP] RTPRI TQNTM TQSIG 16991 0 1000 0

If I run the same code in the Timeshare (TS) or IA (interactive) class the results are the same:

it prints 1002 if I put [] around it and print it, and it prints "a Semaphore()" after about 1 second if I just print the code

Note that in the IA case (which is the default) the vm prints: pthread_setschedparam failed: Not owner This VM uses a separate heartbeat thread to update its internal clock and handle events. For best operation, this thread should run at a higher priority, however the VM was unable to change the priority. The effect is that heavily loaded systems may experience some latency issues. If this occurs, please create the appropriate configuration file in /etc/security/limits.d/ as shown below:

cat <<END | sudo tee /etc/security/limits.d/squeak.conf

•  hard    rtprio  2
  

•  soft    rtprio  2
  

END

and report to the squeak mailing list whether this improves behaviour.

You will need to log out and log back in for the limits to take effect. For more information please see https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/r3732#linux

If I put the vm in the RT class then it doesn't print this warning or error message.

But the behavior of the "test code" in Squeak seems to me the same ...

-- Sent from: http://forum.world.st/Squeak-VM-f104410.html