soft real-time on linux

On 02/09/2017 03:16 AM, Jack wrote:
> Il giorno giovedì 9 febbraio 2017 03:17:31 UTC+1, Phil Hobbs ha
> scritto:
>>
>> The Linux thread scheduler is horribly broken, or was last time I
>> used it (a while ago, admittedly).  The info pages will tell you
>> all about how to specify priorities, scheduling algorithms, and so
>> forth, but leave out two vital items:
>>
>> 1. You can only hack those things if you're running as root, and
>
> the priority of your processes can be modified with "nice". If you
> want to change some kernel config of course you need to be root (same
> thing in any other OS)

Only process-by-process.
>
>> 2. You can't have both real-time and normal threads in the same
>> process.
>
> since threads are created/destroyed dinamically, and the OS can't
> know what the fuck is going on in the thread, it's pretty normal that
> the priority is process based and not thread based.

Not true in Windows, for instance.  It's a serious handicap in my case, 
where I have compute threads and comms threads in a clusterized 
simulator: another box can totally stall waiting for a comms thread on 
the next box to finish its job.  It trashes the scaling--Windows boxes 
scale nearly linearly up to 25 hosts or so, whereas Linux ones start 
getting less efficient at around 8 hosts.

On a single box, the thread scheduler has a global view of what's going 
on, so it isn't as big a deal.

>
> If you want to prioritize a particular thread in a process, you need
> to do it at programming time.
>
> good old stackoverflow:
> http://stackoverflow.com/questions/3649281/how-to-increase-thread-priority-in-pthreads
>
Only works as root, and if you want any thread to be real-time, you have 
to put the whole compute-bound process in the RT class, which brings the 
system to its knees.  What I need is a RT comms thread that is usually 
blocked on a semaphore and then runs furiously about 1% of the time.
>
>>
>> Both (1) and (2) are easy in Windows (or the late lamented OS/2,
>> which
>
> the (1) is "easy" in win because a normal user is automatically
> Administrator, if aou use a user without admin privileges, well you
> can change the priority of your processes, but not others.

But not the relative priority of threads within the process, whereas you 
can in Windows.  As I said originally, I'd be quite happy to be able 
just to _reduce_ the priority of the compute threads vs. the comms 
threads,  but _noooooooo_.  Broken as designed.

Cheers

Phil Hobbs


-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC
Optics, Electro-optics, Photonics, Analog Electronics

160 North State Road #203
Briarcliff Manor NY 10510

hobbs at electrooptical dot net
http://electrooptical.net

On Wed, 8 Feb 2017 21:17:35 -0500, Phil Hobbs
<pcdhSpamMeSenseless@electrooptical.net> wrote:


>The Linux thread scheduler is horribly broken, or was last time I used 
>it (a while ago, admittedly).  

It has improved quite a bit in the recent kernels.  
However ...


>The info pages will tell you all about 
>how to specify priorities, scheduling algorithms, and so forth, but 
>leave out two vital items:
>
>1. You can only hack those things if you're running as root, and
>2. You can't have both real-time and normal threads in the same process.

All of this still is true. 

The scheduler historically had problems dealing with overused and
underused cores, and it has been greatly improved of late.  However
control over scheduling has not changed significantly since 2.6.24
(circa 2008).


>Both (1) and (2) are easy in Windows (or the late lamented OS/2, which 
>is where I learned multithreaded programming, 1992ish).
>
>Note that for my purposes I'd have been totally happy if I could even 
>_reduce_ the priority of some threads in my process to make clear which 
>ones were less important than others.  Not trying to hog other users' 
>gjhresources, no sir.  Still not doable as an ordinary user.

Have you tried using clone(2)?
http://man7.org/linux/man-pages/man2/clone.2.html


Clone is a low level call that can create either new processes or new
(kernel) threads in the same process.  For new processes it gives
quite fine control over the execution environment.

You can, e.g., create a new process that *acts* as though it were a
thread: sharing memory (and/or other environment) with the parent, but
having a different priority, scheduling policy, process group, etc.

It is the best Linux can manage.


>On the other hand, I think you can set processor affinities so as to 
>reserve one or more cores for just your own code.  I hope so, because 
>I'm looking at a similar requirement myself soon. ;)

You can choose which cores will execute your code, but it is very
difficult to prevent other processes from also using your chosen
cores.

You can try to futz with group scheduling to achieve what you want,
but that is clumsy and difficult because it can involve manipulating
process *owners* as well as parent/child relationships and priorities.


I think the best you can do without inviting a whole lot of headache
is to try to refactor your (POSIX?) threaded application into a set of
clone processes.


>Cheers
>
>Phil Hobbs

George