<table><tr><td style="">davidedmundson created this revision.<br />Herald added a project: Frameworks.<br />Herald added a subscriber: kde-frameworks-devel.<br />davidedmundson requested review of this revision.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D27883">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>Having each application in it's own scope brings numerous advantages:</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">PIDs are very yesteryear, a modern application has a tonne of</li>
</ul>

<p>processes. We want some sort of logical grouping in ksysguard.<br />
We have a working version of this.</p>

<p>It also can resolve the case of correctly matching the<br />
audio indicator to the correct application in the task manager.<br />
Something that has been proven to not work reliably by tracking parent<br />
PIDs.</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">We can use the cgroup freezer controller on plasma-mobile to suspend</li>
</ul>

<p>background processes.</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">We want to put things into the correct slice.</li>
</ul>

<p>Future systemd will split user.slice into 3 subslices, background<br />
services, apps and chrome (with chrome being plasmashell and kwin in our<br />
case). Putting applications in the correct slice will bring pre-bumped<br />
niceness levels.</p>

<ul class="remarkup-list">
<li class="remarkup-list-item">We also can expose cgroup resources limits</li>
<li class="remarkup-list-item">Things get cleaned up logout without relying on xsmp.</li>
</ul>

<p>This is analogous to Gnome's recent change:<br />
<a href="https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/863/diffs" class="remarkup-link" target="_blank" rel="noreferrer">https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/863/diffs</a></p>

<p>It was also discussed in person at a very-mini meeting at FOSDEM with<br />
both systemd and gnome people.</p>

<p>Task <a href="https://phabricator.kde.org/T12678" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;">T12678</a></p>

<p>If a relevant cgroup controller (systemd) is not running, this simply<br />
no-ops without issue.</p>

<p>In addition things are guarded by an environment variable so we don't<br />
introduce any behavioural changes to released Plasma's.</p>

<hr class="remarkup-hr" />

<p>This change is incredibly minimal by launching as normal and then<br />
tagging afterwards. It's a bit of a chicken and egg scenario as we merge<br />
the intended usages of this change.</p>

<p>After things are established we will want to move spawning the<br />
application to be responsiblity of the cgroup controller as transient<br />
services rather than transient scopes. It will be more "technically<br />
correct" and allow even more features such as improved logging.</p></div></div><br /><div><strong>TEST PLAN</strong><div><p>Ran app from kickoff, started systemd-cgls<br />
I've been using some variant of this on a private work project for months<br />
Also ran against pending ksysguard modifications that showed applications grouped nicely</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R241 KIO</div></div></div><br /><div><strong>BRANCH</strong><div><div>systemd_start</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D27883">https://phabricator.kde.org/D27883</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>src/widgets/kprocessrunner.cpp<br />
src/widgets/kprocessrunner_p.h</div></div></div><br /><div><strong>To: </strong>davidedmundson<br /><strong>Cc: </strong>kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns<br /></div>