Make the use of the pthread_attr_setschedpolicy optional for linux #404

New Issue

gaisser · 2021-04-16T15:06:56+02:00

gaisser commented

2021-04-16 15:06:56 +02:00

Currently, we try to set the scheduling policy which allows us to set the priorities. For a normal machine this needs root rights or at least a privilige for the binary. This might be unessecary for test purposes on a normal Linux computer. I would suggest:

void PosixThread::createTask(void* (*fnc_)(void*), void* arg_) {

......


#ifdef FSFW_USE_REALTIME_FOR_LINUX
status = pthread_attr_setschedpolicy(&attributes,SCHED_FIFO);
	if(status != 0){
		sif::error << "Posix Thread attribute schedule policy failed with: " <<
				strerror(status) << std::endl;
	}

	sched_param scheduleParams;
	scheduleParams.__sched_priority = priority;
	status = pthread_attr_setschedparam(&attributes, &scheduleParams);
	if(status != 0){
		sif::error << "Posix Thread attribute schedule params failed with: " <<
				strerror(status) << std::endl;
	}
#endif

.....

}

Currently, we try to set the scheduling policy which allows us to set the priorities. For a normal machine this needs root rights or at least a privilige for the binary. This might be unessecary for test purposes on a normal Linux computer. I would suggest: ``` c++ void PosixThread::createTask(void* (*fnc_)(void*), void* arg_) { ...... #ifdef FSFW_USE_REALTIME_FOR_LINUX status = pthread_attr_setschedpolicy(&attributes,SCHED_FIFO); if(status != 0){ sif::error << "Posix Thread attribute schedule policy failed with: " << strerror(status) << std::endl; } sched_param scheduleParams; scheduleParams.__sched_priority = priority; status = pthread_attr_setschedparam(&attributes, &scheduleParams); if(status != 0){ sif::error << "Posix Thread attribute schedule params failed with: " << strerror(status) << std::endl; } #endif ..... } ```

muellerr commented

2021-04-19 14:24:45 +02:00

I think this is good. Can the developer still use the priority system going from 1 to 99 or is this other nice schedule priority system used?

gaisser commented

2021-04-19 17:41:39 +02:00

Hm I think for now we should use the 1 to 99 System for compability with other OS in the case the scheduler is used.

muellerr commented

2021-04-19 18:05:16 +02:00

I think it might then be necessary to convert 1-99 to the nice values:
https://medium.com/@chetaniam/a-brief-guide-to-priority-and-nice-values-in-the-linux-ecosystem-fb39e49815e0

But I am not sure.

I think it might then be necessary to convert 1-99 to the nice values: https://medium.com/@chetaniam/a-brief-guide-to-priority-and-nice-values-in-the-linux-ecosystem-fb39e49815e0 But I am not sure.

gaisser commented

2021-04-20 11:55:54 +02:00

Hm nice values are caped for non-root users. We could map that to 0-19

Note: Only root user can set the nice value from -20 to 19. Other users can only set nice values from 0 to 19.

Another issue:

https://man7.org/linux/man-pages/man7/sched.7.html under Autogroup:

 Under group scheduling, a thread's nice value has an effect for
  scheduling decisions only relative to other threads in the same
  task group.  This has some surprising consequences in terms of
  the traditional semantics of the nice value on UNIX systems.  In
  particular, if autogrouping is enabled (which is the default in
  various distributions), then employing setpriority(2) or nice(1)
  on a process has an effect only for scheduling relative to other
  processes executed in the same session (typically: the same
  terminal window).

 Conversely, for two processes that are (for example) the sole
  CPU-bound processes in different sessions (e.g., different
  terminal windows, each of whose jobs are tied to different
  autogroups), modifying the nice value of the process in one of
  the sessions has no effect in terms of the scheduler's decisions
  relative to the process in the other session.  A possibly useful
  workaround here is to use a command such as the following to
  modify the autogroup nice value for all of the processes in a
  terminal session:

Hm nice values are caped for non-root users. We could map that to 0-19 > Note: Only root user can set the nice value from -20 to 19. Other users can only set nice values from 0 to 19. Another issue: https://man7.org/linux/man-pages/man7/sched.7.html under Autogroup: > Under group scheduling, a thread's nice value has an effect for > scheduling decisions only relative to other threads in the same > task group. This has some surprising consequences in terms of > the traditional semantics of the nice value on UNIX systems. In > particular, if autogrouping is enabled (which is the default in > various distributions), then employing setpriority(2) or nice(1) > on a process has an effect only for scheduling relative to other > processes executed in the same session (typically: the same > terminal window). > Conversely, for two processes that are (for example) the sole > CPU-bound processes in different sessions (e.g., different > terminal windows, each of whose jobs are tied to different > autogroups), modifying the nice value of the process in one of > the sessions has no effect in terms of the scheduler's decisions > relative to the process in the other session. A possibly useful > workaround here is to use a command such as the following to > modify the autogroup nice value for all of the processes in a > terminal session:

gaisser commented

2021-04-20 12:13:44 +02:00

So, we could use the function beaneath to set the nice values. We could recalculate the values to be in range 0,19.

       #include <unistd.h>

       int nice(int inc);

https://man7.org/linux/man-pages/man2/nice.2.html

But at least on my machine getrlimit does not return any sensible thing:

/*
 * get_limits.cpp
 *
 *  Created on: Apr 20, 2021
 *      Author: gaisser
 */

#include <sys/resource.h>
#include "get_limits.h"


int threading::getNiceLimits() {
    rlimit limits= {99, 99};
	int success = getrlimit(RLIMIT_NICE, &limits);
	if (success != 0){
		std::cout << "Error happened while trying to get nice limts: "<< strerror(errno) << std::endl;
	}
	return ((20 - limits.rlim_cur) > (20-limits.rlim_max)) ? (20 - limits.rlim_cur): (20-limits.rlim_max);
}

Gives me a 20. So both are 0. Therefore, I would have to change the limits if I am right.

So, we could use the function beaneath to set the nice values. We could recalculate the values to be in range 0,19. ``` c++ #include <unistd.h> int nice(int inc); ``` https://man7.org/linux/man-pages/man2/nice.2.html But at least on my machine getrlimit does not return any sensible thing: ``` c++ /* * get_limits.cpp * * Created on: Apr 20, 2021 * Author: gaisser */ #include <sys/resource.h> #include "get_limits.h" int threading::getNiceLimits() { rlimit limits= {99, 99}; int success = getrlimit(RLIMIT_NICE, &limits); if (success != 0){ std::cout << "Error happened while trying to get nice limts: "<< strerror(errno) << std::endl; } return ((20 - limits.rlim_cur) > (20-limits.rlim_max)) ? (20 - limits.rlim_cur): (20-limits.rlim_max); } ``` Gives me a 20. So both are 0. Therefore, I would have to change the limits if I am right.

gaisser commented

2021-04-20 12:42:28 +02:00

Ok and I can not set the limits. So, for now lets not set the nice limits

gaisser self-assigned this 2021-04-20 13:04:50 +02:00

gaisser added this to the ASTP 1.0.0 Local pools milestone 2021-04-20 13:04:53 +02:00

gaisser added the

feature

label 2021-04-20 13:04:56 +02:00

gaisser referenced this issue

2021-04-20 13:05:20 +02:00

Makes linux realtime optional #406

muellerr commented

2021-04-20 13:51:59 +02:00

What about the other scheduling policies like SCHED_IDLE or SCHED_DEADLINE
? There is also the option to let the user chose those by using something similar how it was done for Windows: https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/mueller/master/osal/windows/winTaskHelpers.cpp

What about the other scheduling policies like `SCHED_IDLE` or `SCHED_DEADLINE` ? There is also the option to let the user chose those by using something similar how it was done for Windows: https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/mueller/master/osal/windows/winTaskHelpers.cpp

gaisser commented

2021-04-20 14:00:12 +02:00

What about the other scheduling policies like SCHED_IDLE or SCHED_DEADLINE?

Unconfirmed: The change of schedule policies always needs the privileges to do so. The whole reason for this issue was to be able to execute it without root or privileges.

There is also the option to let the user chose those by using something similar how it was done for Windows: https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/mueller/master/osal/windows/winTaskHelpers.cpp

Quote from MS:

The handle must have the PROCESS_SET_INFORMATION access right

So, even on Windows you need at least some access rights, which makes sense because one application could block your whole system.

> What about the other scheduling policies like SCHED_IDLE or SCHED_DEADLINE? Unconfirmed: The change of schedule policies always needs the privileges to do so. The whole reason for this issue was to be able to execute it without root or privileges. > There is also the option to let the user chose those by using something similar how it was done for Windows: https://egit.irs.uni-stuttgart.de/fsfw/fsfw/src/branch/mueller/master/osal/windows/winTaskHelpers.cpp [Quote from MS:](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setpriorityclass) > The handle must have the PROCESS_SET_INFORMATION access right So, even on Windows you need at least some access rights, which makes sense because one application could block your whole system.

gaisser commented

2021-04-20 17:57:25 +02:00

Part of Makes linux realtime optional #406

gaisser closed this issue

2021-04-20 17:57:26 +02:00

Sign in to join this conversation.