Description of problem:
As far as I can see, mcstransd is wasting processor time when idling and
especially when rebuilding RPM packages. I just copied the relevant parts
of the IRC log from Freenode channel #selinux in:
[17:46:39] < rsc> can I remove (the only?) CPU-wasting mcstrans(d) without
messing up my selinux-targeted system?
[17:50:53] < sgrubb> I think you can remove mcstransd if you do not need label
translations and don't mind seing s0.
[17:51:15] < rsc> why was the library removed and replaced by a CPU-wasting
[17:51:40] < rsc> sorry, but mcstrans(d) *is* CPU-wasting here on the dual
x86_32 3.06 GHz machine
[17:51:41] < sgrubb> actually performance and to solve a couple other problems
[17:52:57] < rsc> was libsetrans obsoleted by upstream or was the switch only
another Red Hat decision?
[17:53:08] < sgrubb> upstream
[17:53:32] < rsc> then it would be nice to fix the stuff ;->
[17:53:59] < sgrubb> you mean fix the daemon or fix libselinux ?
[17:55:24] < rsc> both *g* no I mean the daemon, the fscking thing more annoying
rather the library before (okay, I'm not using MLS)
[17:55:47] < rsc> s/more/is more/
[17:56:47] < sgrubb> what is annoying. I might be able to fix it if I understand
what your complaint is. :0
[17:57:07] < rsc> consuming around 7% of CPU all the time on a idling dual
x86_32 3.06 GHz machine looks completely wrong/broken/whatever to me...
[17:57:22] < sgrubb> wow
[17:57:45] < sgrubb> how are you measuring that ?
[17:58:21] < rsc> top/ps
[17:59:25] < rsc> oh and "Unknown/error events (8) encountered for fd (5)" in
syslog are caused by the use of quota (especially during quotaon/-off/check.
Another thing, which wasn't programmed completely... ;-)
[18:00:35] < sgrubb> say, if you strace the mcstransd program is it just idling?
[18:02:26] < rsc> just a "poll("
[18:03:22] < sgrubb> hmm strange that a poll call is taking so much cpu time.
[18:04:00] < rsc> btw, did you ever rebuilt a gcc or glibc when having mcstransd
running? Mcstransd is most of the time between of 30% and 95% of CPU usage (as I
can see per top)
[18:04:58] < sgrubb> No, I haven't. I wonder what is calling it?
[18:06:31] < rsc> replacing mcstransd by libsetrans myself wouldn't work I
guess, wouldn't it?
[18:07:07] < sgrubb> I suspect its major surgery
[18:07:20] < sgrubb> I would chkconfig --del mcstrand
[18:07:39] < sgrubb> or rpm -e its
[18:09:11] < rsc> hehe okay, just like the same with lvm2 to eliminate the
performance problem *G*
[18:09:28] < sgrubb> ok it any build, not just glibc or gcc
[18:09:36] < sgrubb> I saw it
[18:09:48] < sgrubb> now question is who's calling it
[18:10:05] < rsc> do you want a bug report? ;)
[18:10:39] < rsc> but don't tell me I've got to ship it about a Red Hat channel,
like at lvm2... ;)
[18:11:03] < rsc> s/Red Hat channel/Red Hat support channel/
[18:11:28] < sgrubb> rsc, you can file a bug report against fc devel on mcstrans
[18:11:39] < sgrubb> just straight to bugzilla
[18:12:02] < sgrubb> its more like a reminder to me
[18:12:11] < sgrubb> I'm investigating it right now
Created attachment 131149 [details]
performance improvement patch
This patch seems to help performance by avoiding a couple unnecessary syscalls.
This is the callers of mcstransd during a build of libselinux:
Executable Summary Report
Yes, your patch improves the performance - thanks.