Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1054473 - RFE: Backport CGroups optimizations
Summary: RFE: Backport CGroups optimizations
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 20
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-16 21:57 UTC by David Strauss
Modified: 2014-12-09 02:43 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-09 02:43:17 UTC
Type: Bug


Attachments (Terms of Use)

Description David Strauss 2014-01-16 21:57:20 UTC
Upstream patch: http://cgit.freedesktop.org/systemd/systemd/commit/src/core/cgroup.c?id=6414b7c981378a6eef480f6806d7cbfc98ca22a1

Description of problem:
Unit numbers exponentially affect CGroups application during boot time and daemon-reload/daemon-reexec. This take make a system that booted fine under Fedora 19/systemd v204 take hours under Fedora 20/systemd v208. This even affects disabled units.

Version-Release number of selected component (if applicable):
Any systemd v208

How reproducible:
Every boot.

Steps to Reproduce:
1. Create a bunch of units (hundreds to thousands) that use a proportional CGroups controller, like CPUShares.
2. Boot.
3. Wait a really long time.

Actual results:
System takes a really, really long time to reach login.

Expected results:
System takes an amount of time roughly proportional to the number of units it starts.

Additional info:
This patch has been running in production at Pantheon for over a month. We can't boot our boxes without it. It applies cleanly to Fedora's systemd package.

Comment 1 Lennart Poettering 2014-02-23 15:55:00 UTC
If this is backported the more recent fixes to 209 should be backported too, which make sure cgroup membership can be removed again if a cgroup setting is reset.

That said, I am not convinced that this is material to backport, and would suggest leaving this for F21.

Comment 2 David Strauss 2014-02-28 19:10:58 UTC
> If this is backported the more recent fixes to 209 should be backported too, which make sure cgroup membership can be removed again if a cgroup setting is reset.

Agreed.

> That said, I am not convinced that this is material to backport, and would suggest leaving this for F21.

We're currently running both the cgroup performance patch and an interim one for is-enabled performance on our production systems. While I have someone working on an upstream-friendly fix for the latter right now, it may be some time before that's done. As long as we have to patch the RPM at least once, it's about the same effort for us.

In short, I'm fine leaving this un-backported.

Comment 3 Zbigniew Jędrzejewski-Szmek 2014-03-03 13:28:16 UTC
If you have backported patches that work, I'd be great to add them to the v208-stable branch and release them in F20, since F21 is another 6 months away.

Comment 4 David Strauss 2014-03-03 18:26:24 UTC
I know my patch applies cleanly to v208 and is stable in production:
http://cgit.freedesktop.org/systemd/systemd/commit/src/core/cgroup.c?id=6414b7c981378a6eef480f6806d7cbfc98ca22a1

I haven't tried Lennart's follow-up fixes to core/cgroup.c for removing controllers, but they will probably also apply and run fine.

Comment 5 Lennart Poettering 2014-12-09 02:43:17 UTC
I figure we won't backport these anymore. THis is too complex, anf F20 too old. Sorry.


Note You need to log in before you can comment on or make changes to this bug.