pthread_setschedparam failed: Not owner
Locked
 
|
On Solaris when running the bash-4.4$ bin/squeak Squeak5.3-19431-32bit.image *pthread_setschedparam failed: Not owner* (the Squeak image starts up despite the warning/error, it seems to warn that "for best operation, this thread should run at a higher priority, however the VM was unable to change the priority.") I'm not really sure what the right Solaris way to fix this is, but by default the shell has for me bash-4.4$ priocntl -d $$ INTERACTIVE CLASS PROCESSES: PID[/LWP] IAUPRILIM IAUPRI IAMODE 3246 0 0 1 priority limit 0 and priority set to 0 I can raise this with "priocntl -s -m 10 -p 1 $$" to set the limit to 10 and the priority of the shell to 1 (not sure whether that is good idea) in any case in that case bash-4.4$ priocntl -d $$ INTERACTIVE CLASS PROCESSES: PID[/LWP] IAUPRILIM IAUPRI IAMODE 3246 10 1 1 the limit is then 10 when starting from that shell the squeak VM it does *not print the warning*, so perhaps it can succesfully issue the pthread_setschedparam() call. the LWP (light weight process) with "ps" (report process status) shows a difference indeed # ps -eLo class,pri,lwp,pid,comm | grep squeak IA 40 1 3256 bin/../lib/squeak/5.0-202003240214-solaris/squeak IA 51 2 3256 bin/../lib/squeak/5.0-202003240214-solaris/squeak while if the error/warning is printed the "pri' (priority) is the same for the 2 LWP (threads?) # ps -eLo class,pri,lwp,pid,comm | grep squeak IA 49 1 3306 bin/../lib/squeak/5.0-202003240214-solaris/squeak IA 49 2 3306 bin/../lib/squeak/5.0-202003240214-solaris/squeak -- Sent from: http://forum.world.st/Squeak-VM-f104410.html |
|
|
another way to start squeak without the "pthread_setschedparam failed" seems to be to put the shell that starts squeak in the "RT" (realtime class) # priocntl -d 3345 REAL TIME PROCESSES: PID[/LWP] RTPRI TQNTM TQSIG 3345 10 800 0 # ps -eLo class,pri,lwp,pid,comm | grep squeak RT 110 1 3360 bin/../lib/squeak/5.0-202003240214-solaris/squeak RT 111 2 3360 bin/../lib/squeak/5.0-202003240214-solaris/squeak -- Sent from: http://forum.world.st/Squeak-VM-f104410.html |
Re: pthread_setschedparam failed: Not owner
|
|
Hi > On 28.03.2020, at 20:24, stes <[hidden email]> wrote: > > > > another way to start squeak without the "pthread_setschedparam failed" seems > to be to put the shell that starts squeak in the "RT" (realtime class) > > # priocntl -d 3345 > REAL TIME PROCESSES: > PID[/LWP] RTPRI TQNTM TQSIG > 3345 10 800 0 > # ps -eLo class,pri,lwp,pid,comm | grep squeak > RT 110 1 3360 bin/../lib/squeak/5.0-202003240214-solaris/squeak > RT 111 2 3360 bin/../lib/squeak/5.0-202003240214-solaris/squeak The Realtime stuff is actually the reason Squeak uses pthread_setschedparam, to have a reliably timed timing thread :) Best regards -Tobias |
|
|
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 |
Re: pthread_setschedparam failed: Not owner
|
|
Hi Stes, > On Mar 29, 2020, at 1:16 AM, stes <[hidden email]> wrote: > > 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 ? Who knows? The issue here is that we’re not experts in posix thread policies across implementations (apologies to those that are). So by trial and error we find what works. I encourage you to experiment to find out what works. The criteria for success are: 1. a heartbeat thread running at a higher priority than the main vm thread. Verify by creating a process that consumes all cpu and no GC that is terminated by a delay. If the delay fires the heartbeat thread is running, e.g. | 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 2. super user permissions are not required to install the vm with whatever posix thread policy works. I.e. we (I) failed with this in Linux because one needed super user permissions to install the relevant file in etc/security.d that is mentioned in the error message when setschedparam fails. _,,,^..^,,,_ (phone) |
|
|
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 |
|
|
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. -- Sent from: http://forum.world.st/Squeak-VM-f104410.html |
Re: pthread_setschedparam failed: Not owner
|
|
> On 30.03.2020, at 10:27, stes <[hidden email]> 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 |
|
|
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. 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. ... -- Sent from: http://forum.world.st/Squeak-VM-f104410.html |
Re: pthread_setschedparam failed: Not owner
|
|
> On 30.03.2020, at 14:56, stes <[hidden email]> 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. ... |
|
|
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. -- Sent from: http://forum.world.st/Squeak-VM-f104410.html |
Re: pthread_setschedparam failed: Not owner
|
|
Hi > On 30.03.2020, at 19:04, stes <[hidden email]> 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 |
|
|
In reply to this post by stes
Sorry looking a little bit further I see that there is a SPARC version: Squeak-3.7-7.sparc-sun-solaris2.9.tar.gz http://squeakvm.org/unix/release/Squeak-3.7-7.sparc-sun-solaris2.9.tar.gz So the Solaris for SPARC existed but I doubt that it currently still compiles with the Squeak V5 images, but it can be done perhaps. Those "ports" are basically maintaining what existed before. Anyway, the version I compiled for the moment is Solaris 11.3 and Solaris 11.4 for Intel, not for SPARC. -- Sent from: http://forum.world.st/Squeak-VM-f104410.html |
Re: pthread_setschedparam failed: Not owner
|
|
In reply to this post by stes
Hi Stes, > On Mar 30, 2020, at 1:27 AM, stes <[hidden email]> 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 |
|
|
| 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 |
Re: pthread_setschedparam failed: Not owner
|
|
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 <[hidden email]> 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 |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |