Bug 709014

Summary: Optimisation request: selinux costs several seconds during boot (out of 30 total) on old Celeron-M 630 Mhz
Product: [Fedora] Fedora Reporter: Alan Jenkins <alan.christopher.jenkins>
Component: systemdAssignee: systemd-maint
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: dwalsh, eparis, ewalsh, harald, herrold, johannbg, john, lpoetter, metherid, mgrepl, mschmidt, notting, plautrba, sdsmall, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
EeePC 701 ("EeePC 4G")
Last Closed: 2011-12-16 00:35:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alan Jenkins 2011-05-30 12:00:16 UTC
Description of problem:

On a fresh install of F15, systemd-analyze shows ~32s boot time.
Bootchart shows a completely cpu-bound boot process.

Disabling selinux in /etc/selinux/config yields ~11s.


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

Name        : libselinux
Arch        : i686
Version     : 2.0.99
Release     : 4.fc15


How reproducible: Always.


Steps to Reproduce:
1. Install F15 on EeePC 701.
2. Run "systemd-analyze" after boot-up.
3. Compare with selinux disabled v.s. enabled.
  
Actual results:

Boot is no faster than desktop with upstart, parents don't use the netbook :).


Expected results:

Netbook _with SSD_ should ideally be faster to start, allowing parents to save time & electricity on simple tasks e.g. email.  (Assuming everything else works as required... but ya gotta keep on trying :)


Additional info:

RAM: 512Mb.

Comment 1 Alan Jenkins 2011-05-30 12:33:24 UTC
uh... caveats

1) The systemd-analyze comparison may not be the full story.  Bootchart doesn't show such a difference.  It *does* show a reduction in cpu usage of specific processes: 4s less in udevd, 1.5s less in systemd-tmpfiles.  IMO  Bootchart is considering the boot process to end later, in the selinux-disabled case, but it's not as clear as I'd like.  Also, bootup still looks more cpu-bound than io-bound.

The 1.5s delay in systemd-tempfiles can easily be reproduced outside the boot process.


2) I should have said I'm running KDE.  So the startup of the login manager is probably a bit different to a default fedora install.  And this may be affecting the way systemd / bootchart measure the boot process.

Comment 2 Daniel Walsh 2011-05-31 16:13:22 UTC
This time is spent compiling regular expressions in order to setup proper labeling.  We could make systemd a little smarter about its labeling in that it does not need to load all regular expressions at boot, and we could allow it to load them more on demand.

/dev
/var/run
/tmp

Perhaps.

Comment 3 Alan Jenkins 2011-05-31 20:20:55 UTC
To nitpick: when I looked at the 1.5s delay in systemd-tmpfiles, 60% of it was spent in a strcmp() implementation, which callgrind says is called literally 8 million times.  I didn't have the debuginfo to see the caller, but it doesn't sound regex-y.  I just checked the selinux source, and found

nodups_specs()

doing O(n^2) string comparisons which fits almost exactly, for n ~= 4000.

If those strcmp()s could be eliminated, it should save at least 1.5s * 60% * 2 ~= 1.5s.  (label_init() is used at least twice, in both systemd and systemd-tmpfiles).

Comment 4 Daniel Walsh 2011-06-01 13:44:46 UTC
I would guess we should only do this at compile time.  Not sure what problems this would solve except print an error message.  Seems like something we should be able to optionally check.

Comment 5 Fedora Admin XMLRPC Client 2011-10-20 16:27:53 UTC
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Comment 6 Michal Schmidt 2011-12-16 00:35:12 UTC
libselinux in F16 has improved in this regard. It's not doing the O(n^2) dups check anymore.
I don't think performance improvements will be backported to F15, so WONTFIX for that release.

Please reopen and change the Version field if the problem is reproducible in the latest Fedora release.