LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   Set scheduling method per thread, not per process? (https://www.linuxquestions.org/questions/linux-software-2/set-scheduling-method-per-thread-not-per-process-4175646482/)

somanyquestions 01-18-2019 10:27 AM

Set scheduling method per thread, not per process?
 
Hey,

I have read that, in the kernel, since version 2.6.3. or so, Linux does not really schedule processes anymore, but the granularity is actually on the level of threads.
All the functions I see to set scheduling or priority seem to be made for setting everything for processes, though.
E.g. sched_setscheduler, or setpriority, take a process ID, not thread ID.
But if Linux schedules threads anyway - is there a way to set those things on a per-thread basis?


Background:
I have a program that receives a lot of UDP packets at a high, steady rate, and it turned out to be beneficial for setting that process to the "real-time" scheduler SCHED_FIFO, much improving the receive loop time jitter. Since recv() basically yields until a coplete UDP packet is there, as I udnerstood it, this seems like a good scheme.
But not the whole program needs this, and I figure it would be detrimental to overall performance if all other threads of my program also ran with this scheduler.
If I'd use several processes and use e.g. another socket for inter-process communication (at somewhat high data rates), I'm afraid that would produce considerable, unnecessary overhead, data copying. But I haven't actually used inter-process communication (at high data rates, on Linux using POSIX stuff, anyway).
Are those worries unfounded?
Anyway, it seems easier to have one program with several threads - but since the main task of this program is processing the incoming data and forwarding the results, perhaps running this as a service process on its own isn't such a bad idea actually. I just don'thave experience with such things.

Side question:
It confuses me slightly that I can set a "real-time" scheduler on a non-RT kernel. Is this just a "loose terminology" issue that's confusing me and I'm not interpreting things wrong here, and on a real RT kernel I'd just get even better timing?

jefro 01-18-2019 02:39 PM

Just some thoughts....

Actually there are scheduler choices other that what may be in your kernel. "Completely Fair Scheduler (CFS)" is only one of those. It's not complete and not fair in reality.

To be exact, you may have actually a near real time situation. Only a fully RT OS can make a claim of real time. Real time needs to translate to all drivers and that is where Linux had problems way back when it had both real time and normal execution. They could never get the drivers to be fully real time.

This has some basic info. https://www.cs.columbia.edu/~smb/cla...6-4118/l13.pdf


Now to get a thread to do something may require it to be built as a single thread program and then set some priority. Since your issue involves once again some input output then you have to look at the entire chain of events.

You can build kernels to assist in unique tasks. Most distro's offer a desktop workstation kernel build. If you were to build a kernel you may be able to modify it to assist.


Others may have some thoughts on this.

somanyquestions 01-21-2019 03:15 AM

Thanks for that link, looks like a good intro!


All times are GMT -5. The time now is 06:11 PM.