| Summary: | Lots of calls to sighold() in fsexchange when using Solaris doors | ||
|---|---|---|---|
| Product: | STSF | Reporter: | Alan Coopersmith <alan.coopersmith> |
| Component: | ST: Libraries (libST.so and libstsf.so) | Assignee: | STSF mailinglist <stsf> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | minor | ||
| Priority: | medium | ||
| Version: | ST-HEAD | ||
| Hardware: | SPARC | ||
| OS: | Solaris | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
I don't know why fsexchange does this when using doors, but it does:
sighold(SIGINT); sighold(SIGPIPE); sighold(SIGALRM); sighold(SIGPOLL);
ret = door_call(doorfd, &arg);
sigrelse(SIGINT); sigrelse(SIGPIPE); sigrelse(SIGALRM); sigrelse(SIGPOLL);
We'll have to ask Alex why he needed to block signals here, and why a single call
to sigset to hold and release the entire set in one call each was not used.
Without blocking the signals ST Font Server did not work within the X11 environment. X server uses the signals quite extensively and the door calls are interruptable but not restartable (since the font server handler is not idempotent.) I never thought it would be a problem, so I never bothered to implement signal blocking and releasing in a single call. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
Reported by a Sun-internal tester: My desktop running Solaris 10 (build 66) started crawling and then I noticed that Xsun is eating up 68% of CPU. From prstat(1M) # prstat PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 594 ****** 85M 78M run 30 0 14:03:19 68% Xsun/1 796 root 16M 13M sleep 59 0 1:06:25 5.8% stfontserverd/18 [.] I then started Dtrac'ing Xsun and noticed that lwp_sigmask() syscall call is being made too frequently by Xsun. Here is the data : # ./syscall.d ^C Ran for 26 seconds writev 2832 pollsys 3261 read 5910 doorfs 27199 lwp_sigmask 217592 LWP ID COUNT 1 217592 libc.so.1`__systemcall6+0x20 libc.so.1`pthread_sigmask+0x1b4 libc.so.1`sigprocmask+0x20 libc.so.1`sighold+0x54 libST.so.1`fsexchange+0x78 libST.so.1`FSSessionDisposeFontInstance+0x8c 9063 libc.so.1`__systemcall6+0x20 libc.so.1`pthread_sigmask+0x1b4 libc.so.1`sigprocmask+0x20 libc.so.1`sigrelse+0x54 libST.so.1`fsexchange+0xc0 libST.so.1`FSSessionGetFontRenderingParams+0x8c ...and many more such stack traces from libST.so.1`fsexchange(). Infact the stack is like this:- libc.so.1`__systemcall6+0x20 libc.so.1`pthread_sigmask+0x1b4 libc.so.1`sigprocmask+0x20 libc.so.1`sighold+0x54 libST.so.1`fsexchange+0x90 libST.so.1`FSSessionGetFontRenderingParams+0x8c libST.so.1`GetRenderProps+0x344 libST.so.1`GlyphVectorRepQuery+0xf4 libST.so.1`STGlyphVectorQuery+0xd0 SUNWXst.so.1`_XSTUseCache+0x68 See the power of Dtrace. Notice that in this stack trace, we are calling sighold() and sigrelse() too frequently. So this process is disabling and enabling signals for some reason. Looks like we are rendering characters, but why do we block and unblock signals in this path?. Here is the Dtrace script which was used :- #!/usr/sbin/dtrace -s #pragma D option quiet BEGIN { start = timestamp; } syscall:::entry /execname == "Xsun"/ { @s[probefunc] = count(); } syscall::lwp_sigmask:entry /execname == "Xsun"/ { @c[curthread->t_tid] = count(); @st[ustack(6)] = count(); } END { printf("Ran for %d seconds\n\n", (timestamp - start) / 1000000000); trunc(@s,5); printa(@s); printf("\n%-10s %-10s\n", "LWP ID", "COUNT"); printa("%-10d %@d\n", @c); printa(@st); }