OS2 World Community Forum

OS/2, eCS & ArcaOS - Technical => Programming => Topic started by: Doug Clark on February 27, 2025, 04:44:42 am

Title: Stopping CPUs
Post by: Doug Clark on February 27, 2025, 04:44:42 am
I am trying to stop/disable cpus programmatically.  I am calling


DosSetProcessorStatus(cpuNum,0);

Which returns with an error message.  However the cpu is not turned off or stopped.  Is there something else I have to do in addition to calling this function, or should I be calling another function?  Or is it even possible to stop one or more cpus after boot up.

Thanks in advance
Title: Re: stopping cpus
Post by: ivan on February 27, 2025, 02:15:50 pm
Why would you want to do that?  If it is a multi core CPU you no can do unless you open the box and physically remove the CPU.
Title: Re: stopping cpus
Post by: Doug Clark on February 27, 2025, 05:01:17 pm
There are some OS/2 programs, and some Win-OS/2 programs, that do not run well, or at all, when multiple CPUs are enabled, but will run when the system is limited to using a single processor.  The AOS installer is apparently one of those:  the installer program turns off multiple CPUs when it starts.

You can limit the number of CPUs, or processors, used by AOS with the /MAXCPU=1  parameter to the PSD=ACPI.PSD line in CONFIG.SYS.  However this must be done on boot up and that limitation, or setting, remains in effect until another reboot.  I believe this is what the AOS installer does.

It would be nice to be able to turn off and turn on processors as needed.  That way I could turn off all the processors except the main one when running one of those programs, and turn the additional processors back on when the program is done running - without rebooting.  Which is what DosSetProcessorStatus() is supposed to do.

I should add here that I am testing this on a system with a Ryzen 5 processor and the compatibility/legacy support enabled.  I have not tried this on a system with an Intel processor yet.

I should also add that DosSetProcessorStatus() and DosGetProcessorStatus() appear to work, in that they return an error code if I try to set or get the status of a processor that doesn't exist - like processor 7 on my 6 processor Ryzen.  But they don't actually turn off any processors, according to the CPU meter.




 
Title: Re: stopping cpus
Post by: Jochen Schäfer on February 27, 2025, 05:14:21 pm
Essentially, you want something like the CPU affinity feature in Windows. Correct?
Title: Re: stopping cpus
Post by: Doug Clark on February 27, 2025, 05:40:49 pm
Jochen - a similar concept, although for perhaps different reasons.  Quoting from a part of the SMP reference document:

--------------------------------------
...

These compatibility requirements apply only to multithreaded applications, and therefore do not apply to DOS and WINOS2 applications. However, you are strongly encouraged to write 32-bit multithreaded applications for better performance and portability on OS/2 Warp Server for SMP.

Given that there is the possibility of some set of applications which may use one of these techniques, OS/2 Warp Server for SMP provides a mechanism whereby these multithreaded applications can execute in UP mode. Only one thread of that process would be allowed to execute at any given time. That thread could execute on any one of the processors. A utility is used to mark the EXE file as uniprocessor only. OS/2 forces the process to run in the uniprocessor mode when the loader detects that the EXE file has been marked as uniprocessor only. See View and Set Program Type For Executable File (MARKEXE).
--------------------------

Using MARKEXE in OS/2 looks to be somewhat similar to setting processor affinity in Windows.  However I question whether whether OS/2 is honoring the uniprocessor setting in the executable.

I do know that using the /MAXCPU=1 parameter with PSD=ACPI will allow some Win-OS/2 programs to run correctly that will not run without the /MAXCPU=1 setting. So perhaps that parameter is doing more than addressing "one of these techniques" the above quote is referencing. 

The "one of these techniques" from the quote are basically some CPU instructions and techniques that wont work with multiple CPUs.  The processor affinity in windows seems to be aimed at performance issues rather than compatibility issues - some programs run faster with fewer processors.
Title: Re: stopping cpus
Post by: ivan on February 27, 2025, 06:03:33 pm
I see what you are trying to do, maybe you could do what I do when I need to use a win program because friends have brought a win problem to me to solve.  I found an old win XP box at the local dump, replaced the dead power supply, installed win 7 and put it under the bench.  Now if necessary I can start it and so solve the win problems without too much problem - the joys of HDMI cables and selector boxes.
Title: Re: stopping cpus
Post by: Remy on February 27, 2025, 11:45:04 pm
There are some OS/2 programs, and some Win-OS/2 programs, that do not run well, or at all, when multiple CPUs are enabled, but will run when the system is limited to using a single processor.  The AOS installer is apparently one of those:  the installer program turns off multiple CPUs when it starts.

You can limit the number of CPUs, or processors, used by AOS with the /MAXCPU=1  parameter to the PSD=ACPI.PSD line in CONFIG.SYS.  However this must be done on boot up and that limitation, or setting, remains in effect until another reboot.  I believe this is what the AOS installer does.

It would be nice to be able to turn off and turn on processors as needed.  That way I could turn off all the processors except the main one when running one of those programs, and turn the additional processors back on when the program is done running - without rebooting.  Which is what DosSetProcessorStatus() is supposed to do.

I should add here that I am testing this on a system with a Ryzen 5 processor and the compatibility/legacy support enabled.  I have not tried this on a system with an Intel processor yet.

I should also add that DosSetProcessorStatus() and DosGetProcessorStatus() appear to work, in that they return an error code if I try to set or get the status of a processor that doesn't exist - like processor 7 on my 6 processor Ryzen.  But they don't actually turn off any processors, according to the CPU meter.




 

Hi Doug,

You wrote under https://www.os2world.com/forum/index.php?topic=1367.0
the possibility to stop SMP.

Could it be an option here ?

Regards
Title: Re: stopping cpus
Post by: Lars on February 28, 2025, 01:21:25 am
"DosSetProcessorStatus" works perfectly well for me:
Code: [Select]
#define INCL_BASE
#define INCL_DOSSPINLOCK
#include <os2.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
   ULONG procNum = 0;
   APIRET rc = NO_ERROR;
   PCHAR endPtr = NULL;

   if (argc != 2) {
      return 1;
   } /* endif */

   procNum = strtoul(argv[1],&endPtr,10);
   if (procNum < 2) {
      printf("Need to specify a Processsornumber > 1 !\n");
      return 1;
   } /* endif */

   rc = DosSetProcessorStatus(procNum,0);
   printf("DosSetProcessorState, rc:%u\n",rc);

   return 0;
}

It has the same effect as using the "MPCPUMON.EXE" tool that is in the Utilities folder that allows to switch Processor states for each Processor.

1) Processor Numbers are 1-based. A Processor 0 does not exist.
2) in general, you cannot stop Processor 1. It is always necessary to run and attempting to stop it will return error 87 = ERROR_INVALID_PARAMETER. One reason for this is that all interrupt routines always execute exclusively on Processor 1 and of course, as a minimum, you will need 1 Processor to run.

Title: Re: stopping cpus
Post by: Dariusz Piatkowski on February 28, 2025, 04:12:50 am
Ahhh...so I'm going to float an idea here that I have arrived at having personally fought through symptoms such as what you just described, and eventually figure out the relationships at play.

The modern day combination of OS/2 software to support/enable SMP most likely has us all using the ACPI driver, and that by default also means that we have the ACPI daemon managing the CPU/cores according to how you actually configure the system.

What this means is that APCI will attempt to use it's fairly sophisticated logic to enable things such as CPU power saving modes (think of the different CPU Cx states here). Basically these are the PowerManager settings in the acpid.cfg file sitting in \mptn\etc.

Now by DEFAULT the ACPI install has the PowerManager enabled and that also means that ACPI and NOT YOU are deciding what a particular CPU/core should be doing. Heck, on the surface acpid.cfg has enough settings there for you to almost set it up for a nearly seamless "power on when I need it" type of an experience.

....BBBUUUUTTTTT.....that also means that ACPI will insist on being the one who controls your CPU/cores and so subsequently when you are attempting to power off/disable a CPU core using an API call such as DosSetProcessorStatus, it most certainly will, but in the background ACPI will immediately take over and either undo what you just did, or if the system is nearly IDLE it may in fact let that CPU/core stay in disabled status.

This very thing caused me a boat-load of problems b/c on my OS/2 box (4.52, so non AOS install but using the same ACPI release) I occasionally have an OS/2 application that will lock my box (soft freeze, CTRL+ALT+DEL still works to power down) during app startup (I have been told maybe SNAP driver related, I think it is something else), and so I took to using a REXX wrapper to always disable all but a single CPU core before I needed to run such a program. Well, as you can imagine when I moved over to ACPI I all of a sudden was plagued by these soft locks 'once again'...I worked and worked through numerous iterations of configs until I finally discovered that the default ACPI PowerManager settings were occasionally flipping ON one of the just disabled cores and BAM...yup, the lock-up would occur.

Soooo....bottom line here is that on this 24x7 box of mine I do not care at all about how much power that sucker eats up, it is backed up by a 1500W UPS box and stays on all the time, running at full 5.2GHz core speed across all eight of it's cores!

Happy with what I have, combination works for me, but it did require me to disable the ACPI PowerManager.

So what I'm curious about Doug is what that specific error message is that you are seeing? Could it be that DosSetProcessorStatus API was patched to sync it up with the ACPI daemon's logic which is driven by the PowerManager??? That would be fancy, although I doubt that is the case.

Food for thought - I am actually trying to understand the whole ACPI system b/c I'd like to create a little utility that tells us a lot more about what the current hardware configuration, and specifically CPU runtime readings are like, we are talking the Cx core states, the actual frequency different cores are running, heck ACPI is even supposed to give you the ability to see the CPU L1/2/3 cache hit ratios, etc....cool stuff!
Title: Re: stopping cpus
Post by: Dave Yeo on February 28, 2025, 05:12:00 am
Happy with what I have, combination works for me, but it did require me to disable the ACPI PowerManager.

So what I'm curious about Doug is what that specific error message is that you are seeing? Could it be that DosSetProcessorStatus API was patched to sync it up with the ACPI daemon's logic which is driven by the PowerManager??? That would be fancy, although I doubt that is the case.

Food for thought - I am actually trying to understand the whole ACPI system b/c I'd like to create a little utility that tells us a lot more about what the current hardware configuration, and specifically CPU runtime readings are like, we are talking the Cx core states, the actual frequency different cores are running, heck ACPI is even supposed to give you the ability to see the CPU L1/2/3 cache hit ratios, etc....cool stuff!

Don't forget that you can disable/enable PowerMan by changing one line in \mptn\etc\acpid.cfg,
Code: [Select]
[PowerMan]

; Enable: 1=enabled, 0=disabled, default=1
Enable = 1

And the ConfigCheckInterval can be changed from the default of 10 secs if you want a faster result from changing the enabled line.
Personally, my little computer will get too hot with PowerMan disabled though disabling for a while may be acceptable.
Also there is the ACPI sdk, which I've never looked at, IIRC it can be installed from the acpi.wpi.
Edit fix typos
Title: Re: stopping cpus
Post by: Doug Clark on February 28, 2025, 06:20:29 am
1 - the /MAXCPU=1 parameter for PSD=ACPI.PSD driver in CONFIG.SYS  shuts down all processors except processor 1.   Which fixes most of my issues with Win-OS/2 programs that I have - meaning most of those programs will run correctly where they would not without this parameter.  There are still some strange problems with unusual circumstances - mostly when running Win-OS/2 install programs.  Some of those problem applications will run OK in full screen mode with multiple processors running.  Others will only run with /MAXCPU=1.

When /MAXCPU=1 is used with ACPI.PSD only processor 1 is is reported as online with DosGetProcessorStatus().
Attempting to turn on any processor with DosSetProcessorStatus()  when /MAXCPU=1 will result in a error return code of 87 from DosSetProcessorStatus().

2 - Lars - error messages.  DosSetProcessorStatus()  APPEARS to work correctly, in that it does not return an error message if a real processor number is used.  It is just that the processor either is not turned off, or it gets turned back up by something else.  I can tell this because after turning off all processors except processor 1, when I move the window of an open application around the desktop percentages show up for the "turned off" processors in the cpu meter thingy in xCenter.

I have run MPCPUMON.EXE on a second machine (HP EliteDesk with an intel cpu running AOS 5.1 with WSeB  layered on) and basically the same thing happens - percentages show up in the cpu meter for turned off processors. 

3- Dave/Darius - I am afraid to turn off power management after reading the warnings in the ACPI docs - which basically say thermals may become a problem if you mess with power settings.  I did download the ACPI sdk and look through the documentation and I didn't see any function that seemed to address turning on or off processors.  But I might have missed something.

To summarize: 

using the /MAXCPU=1  parameter with PSD=ACPI.PSD fixes most of what ale's me with problem programs. But it requires a reboot to switch back to using multiple processors.  Reboot times with my Ryzen 5 are SLOW.

I suspect, like Darius, that either the processors aren't getting turned off, or something is turning them back on.  This appears to happen on both Ryzen and Intel processors. One using SNAP and the other using Panaroma.

While the SMP reference material from the toolkit say that DOS and Win-OS/2 programs are not affected by SMP, I know from experience that is not true.  The application itself might be single threaded only, but something in the Win-OS/2 system or PM are multithreaded.

Thanks for all the help guys.
Title: Re: stopping cpus
Post by: Dave Yeo on February 28, 2025, 07:03:37 am
Testing turning off PowerMan on this i5-7500, at idle, all 4 cores came online and CPU temperature went from 27C to about 47C, typing this it has gone to 55C. Turning off cores 2-4 in MPCPUMON, temperature has dropped to 38C. (now 32C)
When compiling with 5 jobs, the temperature goes up to close to 70C even with PowerMan enabled here.
My conclusion is that turning off PowerMan and all but core #1 shouldn't stress your system that much, especially if it is a tower or such with good cooling unlike this mini-pc. Just remember to turn PowerMan back on afterwards.
Hmm, now that I've turned PowerMan back on and still typing here, temp is 33-45C with the higher number when more cores are online. ACPI did turn the cores back on when I re-enabled PowerMan.

Doug, does your CPU have SMT I think it is called, similar to Intels Hyper-threading? If so maybe turning that off would fix your DOS problems.
Title: Re: stopping cpus
Post by: Lars on February 28, 2025, 08:16:29 am
DosSetProcessorStatus uses the PSD to do its job. It effectively calls one of the PSD entry points.
And yes, if the PSD decides to manage the CPU power state, it might override what the user wishes to do.
I have turned off power management for ACPI.PSD because it severely slowed down my system (it was too aggressive in turning off CPU cores).
That might be your last resort.
Title: Re: stopping cpus
Post by: Dave Yeo on February 28, 2025, 08:40:30 am
Yes, I tried a Piledriver AMD box and had the same problem. David A. said there was a period where the BIOS's C1 (I think it was C1) was too aggressive at the power savings and caused the problem. Turning off the PowerMan was the workaround I found.
Title: Re: stopping cpus
Post by: Dariusz Piatkowski on February 28, 2025, 04:33:51 pm
Dave, everyone...

Don't forget that you can disable/enable PowerMan by changing one line in \mptn\etc\acpid.cfg,
Code: [Select]
[PowerMan]

; Enable: 1=enabled, 0=disabled, default=1
Enable = 1

Correct, that is exactly how I control whether PowerManager is running, although in my case it is permanently turned OFF.

...And the ConfigCheckInterval can be changed from the default of 10 secs if you want a faster result from changing the enabled line.
Personally, my little computer will get too hot with PowerMan disabled though disabling for a while may be acceptable.
Also there is the ACPI sdk, which I've never looked at, IIRC it can be installed from the acpi.wpi.

Yeah, good point here. There certainly are numerous available parameters that one can tweak in order to get a more "fitting" configuration enabled. In my case, much like what Lars' comment highlighted, having spent a good amount of time working through these I was simply unable to get that balance. The system was always lagging in turning on the CPU/cores when I needed the extra power, this resulted in that "why are things running so slow?" kind of a feel.

I did actually reach out to DavidA (AOS) to work through this, but following several back'n'forth exchanges I was simply told "that's how it works, nothing to change here, it is correct". It is not that he is wrong, I understood all his points but perhaps the ACPI implementation on our platform just can't provide the sort of seamless power transition experience we normally see on other platforms?
Title: Re: stopping cpus
Post by: Dariusz Piatkowski on February 28, 2025, 04:51:02 pm
Hi Doug!

...
3- Dave/Darius - I am afraid to turn off power management after reading the warnings in the ACPI docs - which basically say thermals may become a problem if you mess with power settings.  I did download the ACPI sdk and look through the documentation and I didn't see any function that seemed to address turning on or off processors.  But I might have missed something.
...
I suspect, like Darius, that either the processors aren't getting turned off, or something is turning them back on.  This appears to happen on both Ryzen and Intel processors. One using SNAP and the other using Panaroma.

From a 'good to know how to configure this' perspective the easiest way to TEST this on your machine is to DISABLE the ACPI PowerManager (as per the note that Dave posted, see acpid.cfg file). I believe ACPI daemon dynamically picks this up, so no reboot is necessary.

Then you can shut OFF the cores you do not need running and test your WIN-OS/2 use.

If this work, you know precisely HOW to get this working when you need it working. After all, re-enabling the ACPI PowerManager is just as easy as disabling it. You could literally have a little pm_off.cmd & pm_on.cmd scripts that simply replace the appropriate acpid.cfg files, which ACPI PM then recognizes.

In my experience the big CPU temperature spikes only occur when you really start pushing the machine. We are talking here heavy FLOAT ops such as running the SYSBENCH FLOAT benchmark, etc.

For example: as I play around with this stuff on my end I find that the 48C idle temp of my AMD FX-8370 CPU (8 core, 5GHz) goes up to 51C...which is a pretty tiny amount of just 3C increase. But make note that this is only achieved by deploying the Noctua NH-15D CPU cooler, which is very much in the realm of the overclocking domain.

Prior to installing this cooler I was running a Corsair A70 setup, which was showing 55C at idle and when running the SYSBENCH FLOAT tests the temp would spike all the way to 64C. Heck, a couple of times (as I was screwing around with both CPU frequency and core voltage) I actually had the whole box automatically shut-down.

Soooo....with today's systems there is a good amount of protection built-in...but it's always good to review your specific specs to know exactly what your MAX values are.

Ultimately the experimentation is what will give you the true answers.

EDIT
====

HERE (https://man.netbsd.org/acpicpu.4 (https://man.netbsd.org/acpicpu.4)) is a good summary of all of these C/P/T-states, how they relate to each other, etc.
Title: Re: stopping cpus
Post by: Dave Yeo on February 28, 2025, 05:31:13 pm
Dave, everyone...
...
but perhaps the ACPI implementation on our platform just can't provide the sort of seamless power transition experience we normally see on other platforms?

Here, with my 7th gen I5, and last older one, the power transition experience is very smooth. When more cores are required, they come online quick.
As for other platforms. With Linux things work different. Rather then cores being taken offline and back online, the cores are throttled. At idle they run at 800Mhz and can step up all the way to the boost speed of 3.8Ghz. This happens fast and smoothly. This results in slightly lower temps at idle and hotter temps at full speed with temps over 80C, which is a bit scary.
I don't think on OS/2 that the boost speed ever happens.
Title: Re: stopping cpus
Post by: Pete on March 01, 2025, 01:28:43 am
Hi All

For those considering running with the ACPI PowerManager disabled I can recommend water cooled systems as being less likely to overheat - unless the pump fails :-)


Regards

Pete
Title: Re: stopping cpus
Post by: Doug Clark on March 01, 2025, 08:52:46 pm
Thank you everyone for your responses. 

What utility are you using to get real-time temperatures of the processors?

Title: Re: stopping cpus
Post by: Dariusz Piatkowski on March 02, 2025, 12:10:07 am
Thank you everyone for your responses. 

What utility are you using to get real-time temperatures of the processors?

NONE...and that's the problem on our platform Doug, although there were chipset specific drivers released in the past, but I believe today that's pretty much 'ancient history'.

Well, I should clarify the above statement: I do not have AOS installed, and so there may in fact be some functionality in various utils that are part of AOS.

It is for this reason that I mentioned in my earlier post me currently looking into the ACPI API functionality that perhaps might expose this, assuming our ACPI implementation handles that, which I simply have no idea.
Title: Re: stopping cpus
Post by: Tom on March 02, 2025, 01:25:21 am
What utility are you using to get real-time temperatures of the processors?

If you are using ArcaOS: type acpistat on a command line. At the end of the screen output it says:

Thermal information:
  Thermal zone 'THRM':   Current: 45 C  Critical: 100 C

The value behind 'Current' is what you are looking for.
Title: Re: stopping cpus
Post by: Dave Yeo on March 02, 2025, 01:38:01 am
Thank you everyone for your responses. 

What utility are you using to get real-time temperatures of the processors?

I'm using an xcentre widget from Digi,
Code: [Select]
W:\SYS\apps\xwps\plugins\xcenter>bldlevel cput.dll
Build Level Display Facility Version 6.12.675 Sep 25 2001
(C) Copyright IBM Corporation 1993-2001
Signature:       @#Andrey Vasilkin:1.1.1#@##1## 2017-05-04 14:01:48      DIGI::r
u:RUS:::@@XCenter CPU temperature plugin DLL
Vendor:          Andrey Vasilkin
Revision:        1.01.1
Date/Time:       2017-05-04 14:01:48
Build Machine:   DIGI
Language Code:   ru
Country Code:    RUS
File Version:    1.1
Description:     XCenter CPU temperature plugin DLL

Forget the package it is in now and it only supports Intel CPU's. Arca Noae advises against using it but other then problems with an old Warpin package screwing up config.sys, had no problems.
ACPI might give you the temperatures, run acpistat. The tail here,
Code: [Select]
This system does not support CPU Performance Control via ACPI.

This system does not support CPU Throttling.

Thermal information:
  No Thermal information is available for this computer

No AC status is available for this computer

Power Manager is Enabled

Of course Linux seems to do most of the above :) If you have thermal information available, then there's an xcentre widget, CPU Temperature. Otherwise out of luck.
Title: Re: stopping cpus
Post by: Doug Clark on March 02, 2025, 06:47:02 am
Thanks again guys - Tom, Dave, Darius.

When running ACPISTAT my Ryzen 5/MSI motherboard shows no thermal information available, while the Intel i5 8th gen/HP machine does shows thermal information.  The Ryzen also doesn't support throttling or performance control; the i5 supports throttling.

I am curious Darius what ACPISTAT shows on your Ryzen.



Title: Re: stopping cpus
Post by: Dariusz Piatkowski on March 02, 2025, 04:44:27 pm
Hi Doug!

When running ACPISTAT my Ryzen 5/MSI motherboard shows no thermal information available, while the Intel i5 8th gen/HP machine does shows thermal information.  The Ryzen also doesn't support throttling or performance control; the i5 supports throttling.

So the 'throttling' functionality is something that used to be the orginal/default way of enabling power savings: after all if you were to tell the CPU to get down to just 25% of it's TOTAL output, you would subsequently see less voltage and current draw, less W being produced, and less thermal output.

Today however this functionality has been obsoleted by Power States, where the CPUs themselves are sophisticated enough to calculate the right combination of CPU frequency, voltage needed to support execution at that frequency, and the monitoring of the resulting temperature being generated. Now all that still has to be tied into/with with actual OS level execution and that's where the various ACPI methods come in, and in our case this is why the OS/2 implementation of ACPI uses the PowerManager daemon.

I am curious Darius what ACPISTAT shows on your Ryzen.

So in my case I'm actually using an older AMD CPU, FX-8370, which is a Vishera release of the Bulldozer architecture.

This box is heavily overclocked, which means higher CPU voltage, higher frequency (5GHz as opposed to the default 4GHz and 4.3GHz (boost) frequencies, which in turn requires me to implement specific BIOS settings required to support such an overclocked state. This means that in the BIOS itself I actually turned OFF AMD's C1E function, I shut off the CPU Phase Control function (which is normally motherboard specific as that allows the hardware to dynamically figure out how much power the CPU requires to support execution at a specific user-driven power level) and a few other power control functions.

In the end I do not use the ACPI PowerManager functionality since even if it wanted to control my CPU it wouldn't be able to do so since I had disabled all such BIOS level functionality. Subsequently I have no temperature readout even if I temporarily turn on PowerManager:

Code: [Select]
This system does not support CPU Performance Control via ACPI.

This system supports CPU Throttling. Current=100%

Thermal information:
  No Thermal information is available for this computer

No AC status is available for this computer

No Battery information is available for this computer
Power Manager is Enabled