Hide Forgot
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 daemon? [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 ================================= total file ================================= 9872 /usr/bin/install 1427 /usr/lib/rpm/rpmb 18 /bin/mkdir 12 /usr/bin/find 6 /usr/bin/id
Yes, your patch improves the performance - thanks.