[systemd-devel] Thread level resource management

[Lennart Poettering]

On Fri, 29.11.13 09:33, Umut Tezduyar Lindskog (umut.tezduyar at axis.com) wrote:

> 
> Hi,
> 
> Find my comments below please.
> 
> On Nov 29, 2013, at 9:51 AM, David Timothy Strauss <david at davidstrauss.net> wrote:
> 
> > On Fri, Nov 29, 2013 at 1:58 AM, Umut Tezduyar Lindskog
> > <umut.tezduyar at axis.com> wrote:
> >> Can someone explain the process level management?
> > 
> > Right now, it's possible to do directly in the cgroups file system,
> > but we're eventually moving away from anything manipulating that but
> > systemd. I think that there will still be a way to move around
> > processes via systemd, but it's speculation at this point.
> I am after that “way” you are referring.

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?

Lennart

-- 
Lennart Poettering, Red Hat