[systemd-devel] Thread level resource management

[Lennart Poettering]

On Mon, 02.12.13 15:02, Umut Tezduyar Lindskog (umut.tezduyar at axis.com) wrote:

> > Well, you already can do some bits of it, like using
> > pthread_setschedparam()/pthread_setschedprio() on individual threads.
> > That will allow you to define different scheduling parameters for your
> > threads. This does not allow grouping though. To provide for that there's
> > probably going to be an interface in /proc/self/task/$TID/. At least that's
> > what the kernel guys are discussing right now, if I understood things correctly.
> > 
> > > > Using services will allow you to easily configure resources in a way
> > > > that will continue working through 2014 and beyond as systemd and
> > > > the kernel update. Even with separate services, you can still use
> > > > multithreaded-style (shared memory) techniques by mmapping the
> > same
> > > > paths with MAP_SHARED. There are a bunch of other, standard IPC
> > > > mechanisms, too [1]. It's generally best to decouple the program
> > > > into services that communicate at a high level.
> > 
> > > I think it would be very nice to hear some roadmap on how it is going
> > > to be. I am a bit worried in terms of when/how to start changing
> > > current applications that have been making use of thread level
> > > resource management like gstreamer.
> > 
> > Precisely what kind of thread level resource management is gst doing with
> > cgroups?

>
> Each stream is being handled in an isolated thread and threads cpu
> share is set by cgroups using thread's task id.

What do you mean by cpu share? If this is just a proportional value,
then pthread_setschedparam()/pthread_seschedprio() should suffice, no?
And that even is POSIX and so on... 

Lennart

-- 
Lennart Poettering, Red Hat