Wednesday Jun 13, 2007

Removing XInitThreads from Totem

Bastien, you're not alone. If the JDS team complained to even Sun's X11 team about bugs after they applied that Totem patch, we'd tell them they're on their own and we'd never support an application that called X from multiple threads without calling XInitThreads first.

The Solaris Xlib is thread safe (though probably with a few bugs in corner cases still) based on the same X11R6 multi-thread code as everyone else, though we're currently working to reconcile the fixes from our fork with the current X.Org code as part of our ongoing project to un-fork Solaris X11 and bring it back to the X.Org code base. We're also looking at XCB in the future for a cleaner thread-safety model as well.

Update: As noted by trisk in the comments, this seems to have been caused by known Solaris libXi bug 6551484 - the engineer who had removed XInitThreads() from totem tried the test binary produced by the engineer working on the libXi bug and found it solved the hang problem she was seeing.

Tuesday Nov 28, 2006

My favorite new feature in Nevada build 53...

I wrote a couple of weeks ago about the then-upcoming Solaris Nevada build 53 in a mail to the Solaris x86 YahooGroups mailing list:

For desktop users, nv_53 should be awesome. Gnome 2.16, Firefox 2.0, Gnome System Tools, DRI for i845/i855/i865/i915, and, just integrated today, for the first time ever, the nvidia accelerated drivers/GL as part of the Solaris OS install. Attentive viewers may note that it also doesn't have kdmconfig run at install time anymore due to the replacement of Xsun with Xorg as the install-time X server.

Now that I've updated to nv_53 on my main desktop at work (which was actually a big jump from it's previous Solaris 10 6/06 install, but went smoothly via Live Upgrade) I've found my favorite new feature is one I didn't even know about in advance - a popup menu from the JDS toolbar clock that shows the time in different timezones:

Time Zone Popup Menu screen shot

I work with people from around the world - our desktop team is mostly split between Ireland and China, with outliers in New Zealand, Canada, and Illinois. The Architecture Review Committee I serve on at Sun has members on both coasts of the US, and in India and Isreal at the moment. Trying to keep track of what time it is where is more than I can remember most of the time, so I was constantly going to timeanddate.com to check the time in other parts of the world. Now I can add them to my menu for quick reference.

Unfortunately, it was something I discovered by accident and seems to be a little hidden - to get there, right-click on the panel clock and choose Preferences. In the Clock Preferences panel turn on Show time zones button. You should now have a big world/clock icon next to your clock like the one shown above (one that seems too large and out of place for the panel compared to the other icons there). Click on it to bring up the menu and choose Edit Time Zones. Now, you'll have to ignore the actual question shown in the next dialog:

Even though it's asking you to choose your nearest city, it really means “a city in the time zone and jurisdiction you want to see” — it's neither distance to you that matters or distance to the target, but which set of time zone rules and daylight savings change rules are in effect in the target location. For instance, if you want to know the time in Seattle, Washington, you need to choose Los Angeles, which is much farther away than Boise, Idaho or Vancouver, BC, Canada, but unlike Boise, is in the same time zone, and unlike Vancouver, follows the same national time-shifting schedule. It would be nice if it let you edit the name shown, since I normally think of needing to know the time in Beijing, not Shanghai, but it's still much nicer than what I previously did.

[Technorati Tags: , , , ]

Tuesday Jun 13, 2006

Changing the default login session in dtlogin

At some point over the past few years, I somehow went from just checking in the new login and splash images for CDE in each Solaris release to becoming the unofficial dtlogin “special ops” person - handling the overhauls of the dtlogin appearance for the Solaris 10 beta, 3/05, 1/06, and now 6/06 releases and a few other side tasks that the main CDE sustaining team didn't have the resources to handle. The latest of these is shipping in Solaris Nevada starting in build 39, and I've just gotten the draft of the release note for the upcoming Solaris Express release including it:

Default Desktop Session in dtlogin

Now, when a user logs into the Solaris Desktop for the first time, Java Desktop System (JDS) is the default desktop environment instead of the Common Desktop Environment (CDE). JDS has also become the default environment for users who chose a desktop environment on an older Solaris release that is no longer present in the Solaris release, such as OpenWindows or GNOME 2.0.

System administrators can modify the dtlogin configuration to override the default choices using the defaultDt and fallbackDt resources.

For more information about defualtDt and fallbackDt resources, see the dtlogin(1M)man page.

So users who already chose CDE or JDS will have those choices respected - this only changes the defaults for new users or those whose current session can't be found.

For comparison, the description I wrote for our Architecture Review Committee (ARC) has a lot more technical detail (some of which is now also captured in the above mentioned dtlogin(1M) man page):

This case introduces two new resources in the dtlogin Xresources file
(/{usr,etc}/dt/config/$LANG/Xresources) and establishes initial default
values for those in the Xresources files shipped by Sun.

It requests a patch release binding.

1) Dtlogin\*defaultDt:

   When a new user logs in for the first time, a dialog box is presented
   asking which of the desktop environments installed on the machine they
   wish to use.   The default list currently consists of CDE & JDS, but
   any additional desktops installed using the altDt support in dtlogin
   will appear as well.

   This resource controls which of those desktops is selected by default
   when the dialog appears, so a new user who doesn't know the difference
   and just clicks the OK button will get this desktop, but those who know
   the difference can still choose as appropriate.

   The value of this resource must be the altDtStart value of one of the
   desktop environments installed on the system.   (This was chosen since
   it is the one value required for all desktop environments that must be
   most stable, since it is the one recorded in the lastsession file in
   the users home directory to store their chosen desktop.   The altDtName 
   is localized, so not appropriate for a global default setting.  The
   other values for altDt\* settings are all optional and may not be present
   for certain desktops.)

2) Dtlogin\*fallbackDt:

   When an existing user logs in, but the lastsession file in their home
   directory refers to a program that is not executable on the current 
   system, dtlogin will execute the program listed here as a fallback session.

   This may be any program, including /usr/dt/bin/sdt_firstlogin to offer
   the users a choice of the sessions available on the system.



The default X resources files shipped in Solaris will contain these additions:

!!  Default desktop choice for new users in initial login dialog
!!  This should be the altDtStart key of a session defined here or in
!!  an Xresources.d file.

Dtlogin\*defaultDt:	/usr/dt/config/Xsession.jds

!!  Fallback desktop choice for users whose lastsession file refers to
!!  a non-existent session choice.  Set to /usr/dt/bin/sdt_firstlogin to 
!!  offer the users a choice of the sessions available on the system.

Dtlogin\*fallbackDt:	/usr/dt/config/Xsession.jds

------------------------------------------------------------------------------


Imported interfaces:

dtlogin lastsession mechanism		Project Private	ASARC/1995/390
/usr/dt/bin/sdt_firstlogin		Project Private	ASARC/1995/390

Exported interfaces:

Dtlogin\*defaultDt resource		Stable
Dtlogin\*fallbackDt resource		Stable

Default settings of new resources	Volatile

By declaring these Stable, we're promising that these resources will take values as described and do what we say until further notice. It doesn't prevent us from further changing or refining this in the future (though since we're really trying to replace dtlogin with gdm in the future, we're not likely to do much), it just means that if we do, we'll have to either change these in a compatible way or create new resources. By declaring the defaults as Volatile though, we're warning that we could change them at any time, without warning - for now they're the Xsession file currently used by JDS, but we could change to another mechanism of starting JDS or even (though highly unlikely) to another desktop altogether, without having to worry about having made any compatibility guarantee there.

The note about a “Patch release binding” indicates that we think these changes are compatible enough with current systems to allow shipping this change in a patch or update release (and in fact, this change is being backported to a Solaris 10 patch to be included in the third Solaris 10 update release, tentatively scheduled for release near the end of this year). These changes don't break any existing systems, don't change anything for existing users with a valid desktop choice, still give new users a choice of desktops, and can even be easily overridden by sysadmins who still really prefer their new users be suggested CDE instead of the newer, easier-to-use GNOME-based JDS desktop.

A lot of people think that binary compatibility guarantees that Solaris provides stifle innovation because we can never change things - this is an example of why that's not the case. We don't guarantee nothing about the system will ever change - that would be foolish - what we do is specify what things you can count on remaining compatible (not unchanged, just compatible), and what you can't - and how long that compatibility is promised for. We've never made any promises in the past about what choice would be shown as the default in the session choice dialog, and the Volatile stability for this reflects that we still aren't - but because that's not someting that affects the managability of Solaris systems or the ability of ISV's to provide applications, it's not something we need to make those sort of promises about. The new resources are declared Stable because we don't want admins to use them and then find when they upgrade to a future release that we've broken their settings or made it so their users can't login until they find and fix the problem.

Right now these promises are mostly expressed via the man pages in Solaris - especially the Attributes section in many man pages. The ARC team is also working to open up the processes through which these are set and the history of many of the past review cases that set important ones, via the OpenSolaris ARC community, so that developers will have greater insight into these compatibility promises and eventually even have a voice in shaping them.

[Technorati Tags: , , , ]

Monday Dec 05, 2005

Solaris Desktop Summit: Performance Day 1

The Performance portion of the Solaris Desktop Summit got off to a rousing start today with Bryan's talk on the secrets of the DTrace gurus (or at least all the new bits they've added recently and are still working on documenting in the DTrace Guide.

In the afternoon, we broke into working groups, and I joined the team looking at Boot Time. We split our group further, so I worked with gdm maintainer Brian Cameron on trying to see if we could figure out where we could improve the time it takes to start gdm and the X server once the rest of the system is up. We pieced together enough dtrace to determine that about half of the time was spent in gdmlogin, the program that draws the actual login dialog, about a quarter in Xorg itself, and the rest spread across the other processes involved (including the many svcprop calls from the /usr/X11/bin/Xserver script to get the X preferences from the Solaris SMF registry - an area already noted by others as ripe for improvement).

So we started with the gdmlogin process and dug in - it wasn't long before we hit the limit of my DTrace skills, and we called in Bryan to pinch-hit. [To keep things less confusing in the next part, I'll switch to login names, and refer to Bryan as “bmc” and Brian as “yippi.”] He flew through it - finding things that looked strange and digging in, while yippi looked in the source code for explanations. We saved the scripts and DTrace one-liners on yippi's laptop, and will hopefully be able to post more later. There were three main things we found to investigate/try improving:

  • bmc noticed a lot of time being spent in the close() system call, which seemed strange. Tracking this down to the stack trace involved, yippi saw it was socket closes in the gdmlogin configuration calls. When gdmlogin needs to get a configuration value from the parent gdm daemon it opens a socket, checks the version, asks for the value it needs, then tears down the socket. Over and over again it does this, instead of simply caching the socket and reusing it for future calls, so yippi is looking into seeing if we can convert it to do so.
  • bmc also noticed a lot of stat() system calls, and found two big causes:
    • gdm has a list of possible supported locales and stats the locale directories for each ones to see which are installed. We thought of two ways to reduce the cost of these. First, instead of having gdmlogin do this every time, having the parent do it and pass the list to the children could reduce the time on systems with multiple login screens, such as multiseat systems, including Sun Ray. That shouldn't make much difference on single user system though, but the second idea, to change the scan to instead read the parent directory containing all the locales and use the list of it's subdirs instead of a huge list of all possible subdirs could greatly cut down the number of system calls on systems with only a few locales installed.
    • gdm was also scanning lots of directories to find the icons for the gtk theme, including stat'ing the same directory over and over again. Another group is looking into gtk performance and will be looking into this more.

We didn't get a chance to make all the changes and test the code — at least not before I left, though yippi was still debugging the first set of changes then and if he didn't finish today, we should be tackling it again tomorrow to see if we can measure improvememnts from the changes and find any more or start digging into Xorg.

P.S. John has written a lot more than I did about the Usability portion of the Summit we held last week, including some of the problems we identifies and the ideas we kicked around to solve them.

[Technorati Tags: , , , , , .]

Tuesday Jul 19, 2005

DDC Talk: "Peeking under the Hood"

I've just finished my tutorial presentation on tools for tracing X server/client interactions here at the Desktop Developer's Conference in Ottawa. I've posted both the slides from my talk and the DTrace probes and scripts I showed as one of the tools.

Unfortunately, I didn't get to cover all the tools I wanted to (mostly because I spent a lot more time in the last week on getting the Xorg 6.9 & 7.0 releases ready for their slightly delayed Release Candidate Zero milestones than on my presentation). There are some tools we've developed for our own use in the X group in Sun I was hoping to be able to release before the talk and cover, but didn't get around to - such as a tool that uses the X-Record extension to generate statistics on the number of times each request is called, which we used when switching from CDE to GNOME to determine which parts of the server needed more optimization attention now (Motif & GTK have very different call profiles - for instance, GTK is much more image/pixmap based than Motif was, while Motif use lots of filled rectangles and straight lines to draw it's window decorations and widgets).

About half the talk, and most of the interest though, was in the dtrace probes in the X server (which I wrote about in previous posts). A lot of what I showed was doable before, and in many cases, has been done before, but took much more work. For instance, the X Record program I wrote earlier, and an even older program that post-processed xscope output to produce call counts, both gave counts of the number of times a function was called, but they were a lot more work to write than the simple requests.d script. And that script was easily extended to time-requests.d to instead print the average CPU time the X server took to process each request.

Tip for giving presentations using StarOffice 7 in JDS 3 on Solaris 10: When you want to switch from slide show mode to another window to run a demo, exit slide show mode first in StarOffice, and then switch apps. Trying to Alt-Tab directly did amuse my audience (especially the author of an alternative window manager watching from his comfy spot on the couch), but discovering StarOffice/Metacity interaction bugs during a presentation to a less forgiving audience may not be the best demo of our "integrated" desktop. Fortunately, pkill soffice worked well in the terminal window I had switched to.

[Technorati Tags: , , , , ]

Monday Jul 11, 2005

Can GNOME startup time be improved via ld flags?

Bryan Cantrill, Master DTrace Guru, First Class, spent some time today looking at what exactly GNOME is doing when you login to a Java Desktop System session on Solaris, and posted his findings to his weblog. (The current JDS on Solaris is based on GNOME 2.6, since that's what was the stable release last year when Solaris 10 hit feature freeze. The JDS team is working on an update to GNOME 2.10 now.)

One of the things Bryan found was that a large part of the I/O time was spent loading shared object text. I took a quick look at some of the binaries and libraries using elfdump, and noticed that there were no signs of using flags that could reduce the time needed to load shared libraries at process startup. Some of these (like -z lazyload) defer work until later - others (like -z combreloc) reduce the work needed whenever it happens.

I sent some suggestions to the JDS team on using these flags and others to improve this and suggested especially reading the Performance Considerations chapter of the Solaris Libraries and Linkers Guide for more ideas. I also cc'ed the linker gurus, and Senior Linker Alien Rod Evans added a suggestion to try out the check_rtime perl script on the binaries to check for the recommended flags and whether any of the libraries linked against aren't really needed. It's currently set up for use in the build system of the OS/Networking consolidation (the portion of the Solaris sources already released via OpenSolaris), but should be adaptable to the JDS build system or in fact, any project that wants to try to optimize it's library/linker use on Solaris.

Unfortunately, just tweaking the flags will mostly help Solaris, but the GNU binutils ld used on Linux and some other platforms offers some similar functionality - it recognizes many of the same -z options for instance, though I haven't tried them to see how they compare.

Something that may help more on both platforms is ensuring the libraries listed in the various .pc files for GNOME only list the direct requirements, not all the dependencies they depend on as well. For instance, look at what is linked into every program on Solaris that uses the gtk toolkit:

alanc@unknown:~ [2] pkg-config --libs gtk+-2.0
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lmlib -lpangoxft-1.0 
-lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0
But if you run elfdump -d /usr/lib/libgtk-x11-2.0.so you'll see libgtk-x11-2.0.so already lists those dependencies, so duplicating them in the applications simply wastes time as the linker at runtime will load libgtk-x11-2.0.so and have to check the same list of libraries it already checked in the application (though it should find it's already taken care of them and doesn't duplicate all the work). Additionally it hardcodes in the applications knowledge of the internals and backends used that they shouldn't need to know about, and makes it harder to change or replace one of them. While all those libraries need to be listed when statically linking, or on older systems (mainly pre-ELF I think), the pkg-config entries should be streamlined when using ELF shared libraries on modern systems.

[Technorati Tags: , , , ]
[Now Playing: Deep Space 9 series finale (recorded today off Spike TV by our TiVo)]

About

Engineer working on Oracle Solaris and with the X.Org open source community.

Disclaimer

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle, the X.Org Foundation, or anyone else.

See Also
Follow me on twitter

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today