[systemd-devel] Thread level resource management

Umut Tezduyar Lindskog umut.tezduyar at axis.com
Fri Nov 29 00:33:03 PST 2013


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.
> 
> Your best best, overall, is to break up the program into separate
> *services*. This is hardly a neutral answer, given that you're asking
I find it hard believe that systemd’s resource management will only be in service level. My initial thought was being able to move some of the service processes to a scope unit and then do the resource management but I just couldn’t find any example. Apparently this is not how it is done. 
> on the systemd mailing list. Of course some of us here will advise you
> to break it up into services; systemd is a service-management tool.
> :-)
> 
> 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. 
> 
> [1] http://www.tldp.org/LDP/lpg/node7.html

Thanks,
Umut


More information about the systemd-devel mailing list