Hi,
> -----Original Message----- > From: Lennart Poettering [mailto:lenn...@poettering.net] > Sent: den 29 november 2013 13:49 > To: Umut Tezduyar Lindskog > Cc: David Timothy Strauss; systemd-devel@lists.freedesktop.org; Kay Sievers > Subject: Re: [systemd-devel] Thread level resource management > > On Fri, 29.11.13 09:33, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) > wrote: > > > > > Hi, > > > > Find my comments below please. > > > > On Nov 29, 2013, at 9:51 AM, David Timothy Strauss > <da...@davidstrauss.net> wrote: > > > > > On Fri, Nov 29, 2013 at 1:58 AM, Umut Tezduyar Lindskog > > > <umut.tezdu...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
