[systemd-devel] How to use cgroups for Tracker?

[Lennart Poettering]

On Tue, 14.10.14 15:35, Martyn Russell (martyn at lanedo.com) wrote:

> Hello all,
> 
> Recently I've started looking into support for cgroups due to this bug:
> http://bugzilla.gnome.org/show_bug.cgi?id=737663
> 
> It was suggested I ask you guys to see what the best way forward would be
> here. It seems there are different opinions about how to do this including:
> 
> a) allow the session manager to take care of it.
> b) do it ourselves in Tracker.
> c) do nothing, fallback to cgroups per user which are already in place
>    (depending on distro I guess).
> 
> I personally would rather have a backup plan and go for b) because Tracker
> processes are not always spawned the same way.
> 
> What I had in mind to do, was to use a config file with libcgroup and load
> it in at runtime for processes that are heavy on I/O, CPU and/or Memory.
> From what I understand, this would require permissions to install the
> "profile" at some point (installation? of Tracker) and then just call upon
> that "profile" at run time for a given PID.
> 
> Another option would be to use systemd. However, I am mindful that it's not
> available everywhere just yet (but soon will be I hear) I am also aware, I
> might get a biased answer here :)
> 
> Does anyone have any suggestions or projects that lead by example that
> Tracker could/should follow?
> 
> Orthogonal to all of this, is another idea I had, which is to completely
> pause Tracker when the user is present (keyboard/mouse use) to avoid wasting
> cycles on stuff the user doesn't care about - a bit like how chat clients
> know when you're away or not. Maybe we should do both?

I am not entirely sure what cgroups would really give you that
sched_setscheduler(), ioprio_set(), setrlimit() wouldn't give you
anyway, after all tracker is only a single process, no?

Moreover tracker is unpriviliged and runs in user context (not system
context), right? In that case access to cgroupfs is not available, you
have to go through systemd's per-user APIs. However, currently moving
user sessions to system is not complete, hence I fear its to early to
make this change. Also, at least initially, even if we'd establish
systemd for users widely I have doubts we'll support much more than
CPUShares= for unpriviliged users.

libcgroup is obsolete btw. And while this is currently not strictly
enforced there is supposed to be only one writer to the cgroup tree,
and on most systems that is systemd.

Anyway, what precisely are you trying to do? Why don't the kernel API
calls pointed out above not suffice?

Lennart

-- 
Lennart Poettering, Red Hat