[systemd-devel] Thread level resource management

[Umut Tezduyar Lindskog]

Hi,

> -----Original Message-----
> From: Lennart Poettering [mailto:lennart at poettering.net]
> Sent: den 29 november 2013 13:49
> To: Umut Tezduyar Lindskog
> Cc: David Timothy Strauss; systemd-devel at lists.freedesktop.org; Kay Sievers
> Subject: Re: [systemd-devel] Thread level resource management
> 
> 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?
Each stream is being handled in an isolated thread and threads cpu share is set by cgroups using thread's task id. 
> 
> Lennart
> 
> --
> Lennart Poettering, Red Hat