On Mon, 02.12.13 15:02, Umut Tezduyar Lindskog (umut.tezdu...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
