Tuesday July 19, 2005
alanc @ sun.com
Alan Coopersmith’s blog
Random thoughts of a disorganized mind...
(and though it should be obvious, while Sun pays me to think about things, they disclaim any responsibility for these thoughts, nor do I claim what I say matches in any way what Sun thinks)
Loading...
Tuesday July 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: Xorg, dtrace, DesktopCon, Solaris, OpenSolaris]
Posted at 07:54AM Jul 19, 2005 by Alan Coopersmith in X11 | Comments[1]
Tuesday July 12, 2005
xscope
BTW Donnie, it looks like you found an old version of xscope. A better source (the best public one I know of) is on Keith's CVS server under /cvs/xscope. It has added support for a number of extensions, including Render, RandR, MIT-SHM, and BigRequests. (Unfortunately, I haven't had a chance to bring these enhancements into the xscope we ship in Solaris yet.)
I also thought we released xscope patches as part of our X11/IPv6 source release from Sun to convert xscope to using Xtrans for connections so it can use transport types other than IPv4-only TCP sockets, such as IPv6, Unix domain sockets, or local pipes, but I can't find them online at the moment. Perhaps if we ask Keith nicely he'll import his xscope sources onto freedesktop.org so we can all contribute patches like that and autotool it. We've discussed before setting up a xorg/contrib area in the Xorg CVS tree on freedesktop.org for programs that need a home but which we don't intend to make part of the official full releases (similar to the old ftp.x.org contrib directory or GNOME's "Fifth Toe").
I might even be able to dig up the sources to the xplayback program we've had inside Sun for years to take raw output from xscope and replay it so that you can try to reproduce X bugs without needing the exact same software/environment as the person reporting a bug. It doesn't work in all cases, but has proved useful a few times.
[Technorati Tags: Xorg, X11, IPv6, Solaris]
Posted at 11:36PM Jul 12, 2005 by Alan Coopersmith in X11 |
Monday July 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.0But 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:
GNOME,
dtrace,
Solaris,
OpenSolaris]
[Now Playing: Deep Space 9 series finale (recorded today off Spike TV by our TiVo)]
Posted at 11:01PM Jul 11, 2005 by Alan Coopersmith in Solaris | Comments[2]
Cylons using Sun Ray technology?
Craig asked a bunch of questions yesterday as he was trying to catch up on the new Battlestar Galactica. I posted a comment with some answers, but I realized this evening while making dinner that I missed a point that would really appeal to Craig - the Cylons are, like Sun Rays, ultra-thin clients. If the hardware is damaged beyond repair, the memories and consciousness (as much as a cybernetic being can be said to have one) is instantly transferred to a replacement hardware client. You don't even need to plug in a smartcard to the new Cylon body - it's automatic session migration.
Of course the problem with this is, it puts Sun on the wrong side of this galactic battle - for in the universe of the modern BSG, the network isn't just the computer, it's the very fabric of the Cylon civilization. Our ragtag team of survivors trying to escape genocide at the hands of the Cylons, however, is led by a ship designed to be completely non-networked, with all systems as isolated as possible to reduce the damage that can be done by a network attack. Oh well, you can't win them all (though the highly networked Cylons seem to be winning a lot of them so far).
(So who is going to make a back-and-forth red LED display add-on for the Sun Ray 170 so we can all have our own personal Cylons? It could even be functional - make the speed vary with the amount of bandwidth being used by the Sun Ray or the packet loss rate for remote deployments.)
[Technorati Tags: Battlestar Galactica, Sun Ray]
Posted at 09:54PM Jul 11, 2005 by Alan Coopersmith in General | Comments[3]
Sunday July 10, 2005
Tasty bookmarks from del.icio.us and Yahoo
Many of the Sun bloggers have also discovered the social bookmarking site del.icio.us and a bunch have written about it (see for instance blog posts by Claire Giordano, Claire again, Danny Malks, and Bryan Donovan - amazingly, none of them mentioned that the del.icio.us database server is running on a set of Sun dual-opteron machines). I've been using it for a while both to store and share links, and by subscribing to RSS feeds for a couple tags, to discover new links. Having a common place to store links that's available from my laptop, my home computer, my Sun desktops, and any other computers I'm near is very convenient. So when I read about http://de.lirio.us, a del.icio.us clone that was built using the open source Rubric software, I thought it would be great to use it to build a social bookmarking site inside Sun's firewall, to help people organize and share links to the thousands of web sites and pages inside Sun's firewall. It took a couple of months to find enough spare time to do it, but I finally got it all ready last month and sent out e-mail to our internal bloggers e-mail list. (It turns out quite a few people had the same idea, but I was simply the first to get it all put together and tell others about it.)
When I sent out mail about the internal rubric site, one of the responses asked if sites like del.icio.us and de.lirio.us helped when searching for things. At the time I said that it didn't really - it helped me more in discovering sites, saving links for later use from multiple locations/compuers, and sharing links with others. Now though, Yahoo has added an interesting twist which may make social bookmarking more interesting in it's My Web 2.0 Beta, which takes a del.icio.us style tagged/social bookmark service and adds communities of people who share bookmarks, so you can search through the sites bookmarked by the people in your community. Right now it looks like it's limited to a single community per user, your contacts, but if this could be extended to have multiple named communities, such as an OpenSolaris or X.Org community, it could get really interesting.
(BTW, you can find my shared bookmarks on del.icio.us as alanc and on Yahoo My Web 2.0 as adcoopersmith. And the link currently bookmarked more than any other on our internal social bookmarking site? Why, BlastWave of course.)
[Technorati Tags:
del.icio.us,
de.lirio.us,
rubric,
social bookmarking,
Yahoo
]
[Now playing: The 4400 ]
Posted at 10:24PM Jul 10, 2005 by Alan Coopersmith in General |
Saturday July 09, 2005
New X Test Suite ready for . . . umm, testing
Kevin posted the details yesterday on downloading and running the X Test Suite for people who can help testing the upcoming Xorg 6.9 and 7.0 releases on as many platforms and hardware combinations as possible. If you can help out, please see his message for instructions.
This is also the public debut of the new X Test Suite, which is based on the VSW5 Test Suite which has long been part of the standards compliance certification process for the Unix ® 98 Workstation brand from The Open Group (TOG). Unfortunately, it was only available under a restrictive license before, but in April, the X.Org Foundation announced that TOG and ApTest (who designed the automated testing framework VSW5 uses) had agreed to release it under the MIT/X open source license. The X.Org Test Working Group under Stuart Anderson will be maintaining and enhancing the test suite to expand coverage to many of the newer technologies not currently covered.
[Technorati Tags:
Xorg,
Linux,
BSD,
Solaris,
Unix
]
[Now playing: Live8 replays on VH1 & MTV (Music on MTV? How shocking!) ]
Posted at 03:17PM Jul 09, 2005 by Alan Coopersmith in X11 |
Friday July 08, 2005
Xserver provider for DTrace
A few months ago I sent mail to Sun's dtrace and X11 internal mailing lists about something I'd been playing with:
After trying to absorb as much as possible at last week's dtrace classes, I sat down with the manual and tried things out for a bit to help it sink in before I forgot it all. One of the chapters I stumbled across was the one on adding your own probes to your own applications, which reminded me of some conversations I'd had with various people (Bart and Mahmood and others I've probably forgotten). Caffeine was consumed, and one thing led to another, and after a push in the right direction from the dtrace-interest list...
# dtrace -l -n 'Xserver*:::'
ID PROVIDER MODULE FUNCTION NAME
4 Xserver848 Xsun Dispatch request-start
5 Xserver848 Xsun Dispatch request-done
6 Xserver848 Xsun InitClient client-connect
7 Xserver848 Xsun CloseDownClient client-disconnect
# dtrace -q -n 'Xserver*:::request-start { t = vtimestamp } \
Xserver*:::request-done { \
printf("Client: %3d Request: %20s Size: %5d Time: %10d\n", \
arg3, copyinstr(arg0), arg2, vtimestamp -t)}'
Client: 4 Request: X_SetClipRectangles Size: 5 Time: 46736
Client: 4 Request: X_ChangeGC Size: 4 Time: 16307
Client: 4 Request: X_CopyArea Size: 7 Time: 68328
Client: 4 Request: X_SetClipRectangles Size: 5 Time: 26480
Client: 4 Request: X_ChangeGC Size: 4 Time: 8833
Client: 4 Request: X_PolyFillRectangle Size: 5 Time: 43680
Client: 4 Request: X_SetClipRectangles Size: 5 Time: 28506
Client: 4 Request: X_ChangeGC Size: 4 Time: 11920
Client: 4 Request: X_CopyArea Size: 7 Time: 46566
[sitting at the dtlogin screen, watching the cursor blink - it could probably cache the GC's and clip lists and use a little less bandwidth and CPU to blink that cursor]
This script waits for the next client to connect, keeps a count of all the requests it makes, then prints the count and exits when that client does:
#!/usr/sbin/dtrace -s
string Xrequest[uintptr_t];
Xserver$1:::client-connect
/clientid == 0/
{
clientid = arg0;
printf("\nClient %d connected - tracing requests from it\n", clientid);
}
Xserver$1:::client-disconnect
/clientid == arg0/
{
printf("\nClient %d disconnected - ending trace\n", clientid);
exit(0);
}
Xserver$1:::request-start
/Xrequest[arg0] == ""/
{
Xrequest[arg0] = copyinstr(arg0);
}
Xserver$1:::request-start
/arg3 == clientid/
{
@counts[Xrequest[arg0]] = count();
}
This started out as a plaything to give me something to learn dtrace with, but it looks useful to me and could easily turn into something more if others see uses for it. Since some of these probe points are directly in the hottest code path of our benchmarks, we'd have to make sure that they don't affect our benchmark scores too much, but that shouldn't be much of a problem. Yes, you can do much of this with xscope, but this doesn't require tunnelling everything through the slow xscope proxy server and then finding some way to make sense of the huge output logs.
And I've just put probe points in the easiest and most obvious places - there's other interesting places we could put in probes - when a client does a grab for instance, or on outgoing events and/or errors.
So I guess this is also a request for comments - would others find this useful? What probe points would be useful to use in the X server and what data would you like to get out at those probe points?
For instance, this is what I picked to make available in the current probes:
request-start: request name/extension name, minor code (for extensions),
request length, client id, client sequence
request-done: request name/extension name, minor code (for extensions),
request length, client id, result code
client-connect & disconnect: client id
After some feedback from people, I made some refinements to the existing probes, and added some more probes, then made it available for internal use. Since then I've added a few more probes to help in tracking down the CDE window manager pixmap leak I blogged about earlier. And now, I've made it available outside Sun as well, so more people can try it out, see if the probes available are useful or if they should be modified or expanded, and give feedback on it. At some point I hope to integrate this directly into both the Xsun and Xorg servers delivered in Solaris, as well as into the open source Xorg server code, but I'd like to get some more experience with it from more people first.
After you install it, you should see this set of probes available: (the number after "Xserver" in the provider name is the process id of the currently running Xorg server process)
# dtrace -l -n 'Xserver*:::'
ID PROVIDER MODULE FUNCTION NAME
4 Xserver1335 Xorg FreeClientNeverRetainResources resource-free
5 Xserver1335 Xorg FreeResourceByType resource-free
6 Xserver1335 Xorg FreeResource resource-free
7 Xserver1335 Xorg Dispatch request-done
8 Xserver1335 Xorg EstablishNewConnections client-connect
9 Xserver1335 Xorg AllocLbxClientConnection client-connect
10 Xserver1335 Xorg CloseDownRetainedResources client-disconnect
11 Xserver1335 Xorg CloseDownClient client-disconnect
12 Xserver1335 Xorg ProcKillClient client-disconnect
33598 Xserver1335 Xorg Dispatch client-disconnect
33667 Xserver1335 Xorg AddResource resource-alloc
33668 Xserver1335 Xorg Dispatch request-start
33669 Xserver1335 Xorg ClientAuthorized client-auth
33670 Xserver1335 Xorg FreeAllResources resource-free
33671 Xserver1335 Xorg FreeClientResources resource-free
One of the example scripts I've also made available, client-watch.d reports every client that connects and when it disconnects a count of how many X requests it made and how much time the X server spent processing them. For example, I captured this from logging into and then out of a Java Desktop System (GNOME 2.6) session on Solaris 10:
connect -> id: 8 client id -> id: 8 is from local process 1706 (/usr/bin/gnome-session) 1706: /usr/bin/gnome-session [...] connect -> id: 14 client id -> id: 14 is from local process 1831 (/usr/bin/nautilus) 1831: nautilus --no-default-window --sm-client-id default3 connect -> id: 15 client id -> id: 15 is from local process 1833 (/usr/bin/gnome-volcheck) 1833: gnome-volcheck -i 30 -z 3 -m cdrom,floppy,zip,jaz,dvdrom --sm-client-id default connect -> id: 16 client id -> id: 16 is from local process 1857 (/usr/lib/clock-applet) 1857: /usr/lib/clock-applet --oaf-activate-iid=OAFIID:GNOME_ClockApplet_Factory --oaf connect -> id: 17 client id -> id: 17 is from local process 1831 () 1831: nautilus --no-default-window --sm-client-id default3 connect -> id: 18 client id -> id: 18 is from local process 1859 (/usr/lib/wnck-applet) 1859: /usr/lib/wnck-applet --oaf-activate-iid=OAFIID:GNOME_Wncklet_Factory --oaf-ior- connect -> id: 19 client id -> id: 19 is from local process 1867 (/usr/lib/gnome-netstatus-applet) 1867: /usr/lib/gnome-netstatus-applet --oaf-activate-iid=OAFIID:GNOME_NetstatusApplet connect -> id: 20 client id -> id: 20 is from local process 1875 (/usr/lib/mixer_applet2) 1875: /usr/lib/mixer_applet2 --oaf-activate-iid=OAFIID:GNOME_MixerApplet_Factory --oa connect -> id: 21 client id -> id: 21 is from local process 1877 (/usr/lib/notification-area-applet) 1877: /usr/lib/notification-area-applet --oaf-activate-iid=OAFIID:GNOME_NotificationA [... logout of JDS ...] disconnect -> id: 16, lifetime: 8508 ms, requests: 364 (55 ms of CPU time) disconnect -> id: 12, lifetime: 9597 ms, requests: 979 (50 ms of CPU time) disconnect -> id: 20, lifetime: 6908 ms, requests: 286 (2 ms of CPU time) disconnect -> id: 19, lifetime: 7157 ms, requests: 424 (53 ms of CPU time) disconnect -> id: 14, lifetime: 9466 ms, requests: 940 (1532 ms of CPU time) disconnect -> id: 15, lifetime: 9389 ms, requests: 119 (0 ms of CPU time) disconnect -> id: 13, lifetime: 9542 ms, requests: 4544 (209 ms of CPU time) disconnect -> id: 21, lifetime: 6718 ms, requests: 308 (1 ms of CPU time) disconnect -> id: 8, lifetime: 15691 ms, requests: 1607 (1530 ms of CPU tim disconnect -> id: 7, lifetime: 15851 ms, requests: 16 (0 ms of CPU time) disconnect -> id: 10, lifetime: 11327 ms, requests: 130 (0 ms of CPU time) disconnect -> id: 17, lifetime: 8483 ms, requests: 16 (0 ms of CPU time) disconnect -> id: 18, lifetime: 7402 ms, requests: 789 (14 ms of CPU time)
I've also made the request itself available to copy in so you can get any part of it you want. An example of tracing the CreatePixmap and FreePixmap calls from a single client during a JDS session:
# ./client-pixmaps.d 1306 \"/usr/bin/nautilus\" Creating pixmap: id: 0x1c00004 size: 1,1 Creating pixmap: id: 0x1c0001e size: 48,35 Creating pixmap: id: 0x1c0002a size: 48,48 Creating pixmap: id: 0x1c0002c size: 48,48 Freeing pixmap: id: 0x1c0001e Freeing pixmap: id: 0x1c00025 Creating pixmap: id: 0x1c0002d size: 48,48 Creating pixmap: id: 0x1c0002f size: 48,48 Freeing pixmap: id: 0x1c0002a Freeing pixmap: id: 0x1c0002c Creating pixmap: id: 0x1c00030 size: 48,48 Creating pixmap: id: 0x1c00032 size: 48,48 Freeing pixmap: id: 0x1c0002d Freeing pixmap: id: 0x1c0002f Creating pixmap: id: 0x1c0003f size: 2,2 Creating pixmap: id: 0x1c00041 size: 1024,768 Creating pixmap: id: 0x1c00025 size: 48,35 Creating pixmap: id: 0x1c00047 size: 48,48 Creating pixmap: id: 0x1c00049 size: 48,48 Freeing pixmap: id: 0x1c00030 Freeing pixmap: id: 0x1c00032 Creating pixmap: id: 0x1c0004a size: 1024,768 Creating pixmap: id: 0x1c0004e size: 1,1 Freeing pixmap: id: 0x1c0004e Creating pixmap: id: 0x1c00051 size: 1,1 Freeing pixmap: id: 0x1c00051 Freeing pixmap: id: 0x1c0004a Creating pixmap: id: 0x1c00059 size: 1,1 Freeing pixmap: id: 0x1c00059 Creating pixmap: id: 0x1c0005b size: 109,496 Freeing pixmap: id: 0x1c0005b Freeing pixmap: id: 0x1c00064 Creating pixmap: id: 0x1c00075 size: 1024,768 Freeing pixmap: id: 0x1c00075 Creating pixmap: id: 0x1c00064 size: 1024,768 Creating pixmap: id: 0x1c00086 size: 1024,768 Freeing pixmap: id: 0x1c00086 Creating pixmap: id: 0x1c00097 size: 199,384 Freeing pixmap: id: 0x1c00097 Creating pixmap: id: 0x1c000a0 size: 199,384 Freeing pixmap: id: 0x1c000a0 Creating pixmap: id: 0x1c000a9 size: 1024,768 Freeing pixmap: id: 0x1c000a9 Freeing pixmap: id: 0x1c00047 Freeing pixmap: id: 0x1c00049 Freeing pixmap: id: 0x1c00041
(This simple example just traces - but I'm sure you could enhance it or write a perl script to post-process the output to find pixmap leaks without much trouble, and even from just the trace I note nautilus is creating pixmaps the size of the entire root window (1024 x 768 due to the video card currently in this test machine) more often than I expected it to - all I did for this test was login and choose the menu item to log out.)
Please let me know if you find this useful, find more places that probes would be useful, or have other suggestions. You can reach me via e-mail, comments on this blog, or share with myself and other interested people in the OpenSolaris discussion forums/mailing lists for the dtrace and/or the X Window System.
Meanwhile, if you've got your own applications you'd like to add probes to like this, see Bart's blog on putting developer-defined DTrace probe points in an application, Alan H's blog on statically defined dtrace probes, and the Statically Defined Tracing for User Applications chapter of the DTrace manual.
[Technorati Tags: Xorg, dtrace, Solaris, OpenSolaris]
Posted at 05:26PM Jul 08, 2005 by Alan Coopersmith in Solaris | Comments[2]
Wednesday July 06, 2005
Xorg 6.9 and 7.0 for Solaris
Two comments on my last blog entry asked questions that I thought should be answered in a new entry so that it would be seen by more people, since I expect many people will want to know the answers.
Laurent asked:
And, in an area that concernes you more directly, whare is the current plan at Sun with those new versions? Will 6.9 or 7.0 make it in Solaris 10 at some point, or will it wait for Solaris 11?One of the reasons we (X.Org) are doing 6.9 and 7.0 from the same codebase is to allow distributors to move quickly to 6.9, dropping it in their existing build and package setups as a replacement for 6.8.2. They can thus get the new hardware support, bug fixes, and features out to their users with 6.9, and work on migrating their build systems and packaging to 7.0 at their own pace, without worrying about holding their users behind. Hopefully, by the time 7.1 comes out approximately 6 months after 7.0, most distributors will be ready to adopt it.
So for Solaris, we (Sun) will probably take advantage of this, integrating 6.9 into our builds for Solaris Nevada (the development branch for the next full release of Solaris), and then once it's had some "soak time" there to shake out any issues, will backport that into the next available Solaris 10 Update Release (which will also involve building patches for earlier Solaris 10 releases, as you can see today with the patches to upgrade Solaris 10 from Xorg 6.8.0 to 6.8.2 which we produced in order to include 6.8.2 in Solaris 10 Update 1). It's too early to say exactly which update release that will happen in, as it depends on various schedules and priorities that aren't fully set yet.
Once that's in place, then we'll look at moving to the 7.0 build system. I'm tempted to use this migration as an opportunity to also move our customized build and packaging systems for X in Solaris to one more like those used in other Solaris consolidations such as the OS/Networking sources already released via OpenSolaris, or possibly to the RPM-inspired pkgbuild used by Sun's Java Desktop System teams, to reduce the number of build/packaging systems that people need to learn.
Andrew Watkins posted:
I am wondering what Sun will do about X.org on Sparc. I have not played with x86, but I beleive that X.org is better than Xsun and may even solve the memory leaks (500M currently) Any thoughts or is it X.org for x86 and Xsun for Sparc!To answer this, it may help to understand some history. The group I work in at Sun is responsible for the core X technologies - the server, libraries, and clients. Before we shipped Xorg, we didn't ship any of the video card "driver" modules (except for really old cards - the only one left in our Xsun tree today is cg6, the last of the Sbus graphics). The SPARC hardware organization that produces the graphics cards for SPARC workstations makes the drivers for them, the Sun Ray group provides their modules as part of the Sun Ray Server Software, and the x86 platform driver team delivered the x86 modules for Xsun. With Xorg, we've worked with the x86 group so that we just ship the x86 drivers out of the open source tree builds we do. Unfortunately, the open source tree doesn't contain any drivers for modern SPARC graphics cards (I haven't dug out an old enough system, but think it could work on Solaris SPARC with the suncg6 driver in the Xorg source), nor for Sun Ray, so Xorg isn't useful on SPARC yet. Our group is working with the Sun Ray & SPARC graphics groups to try to change this in the future, but I can't say how long it will take for those groups to be ready to ship.
We would like to see Xorg available on all Solaris desktops, and believe it will bring both improved performance and new features - some already here, like dynamic desktop resizing, some still in the future, like Project Looking Glass - but Xsun is still important to us and many of our users. At this point, I'm not aware of any sizable memory leaks in Xsun that haven't been fixed (though the patches are still being tested for a recent fix, for pixmap leaks in Xinerama mode on Sun Rays, so you probably haven't seen those yet). If there are still leaks of a large size in Xsun, we want to know so we can fix them - but be warned that most reports of X server memory leaks turn out to be from one of two misunderstandings of X. Due to the way video card memory is mapped in X, X servers often appear in 'ps' and the like as using much more memory than the actual RAM or swap space used. On Solaris, you can use pmap to look at the various memory mappings to see which are from video cards and which are actual allocations. The other issue is that clients allocate space in the server for things like pixmaps, and the server can't free it up until the client either releases it or exits, so the "leak" could be in a long-running client, such as your web browser. The xrestop program can be used with Xsun on Solaris 9 or 10 (or on recent XFree86 and Xorg releases on other OS'es) to see how much each client has allocated.
And while I'm on that topic, in just over a week I'll be giving a talk on how to use tools like xrestop, xscope, dtrace, etc. to help track down issues with X clients at the 2005 Desktop Developer's Conference. Since I'm running on my usual schedule (a bit late, but I am on vacation this week), I haven't gotten it all put together yet, so if anyone wants to suggest additional tools to cover, or things you want to know how to observe in X server/client interactions, now would be an excellent time to drop me an e-mail or leave a comment here.
Posted at 11:15PM Jul 06, 2005 by Alan Coopersmith in Solaris |
Monday July 04, 2005
Xorg 6.9 and 7.0 starting to freeze for release
In just a little under 12 hours from when this is posted (at the end of the day on July 4 in Hawaii time) the first phase of code freezes begins for the Xorg 6.9 and 7.0 release cycles. After this, new features will have to either get special permission from the release managers or wait until after the 6.9 and 7.0 releases ship (currently planned for the end of September). Features that add new files or changes to configuration scripts are less likely to be allowed than those that don't, since those changes are going to require more work to synchronize between the two build systems (Imake for 6.9, autoconf/automake for 7.0) and tree layouts (the 6.9 monolith and 7.0 modular). We're also more likely to accept changes that flesh out features already added, such as adding EXA support to more drivers, than those that are completely new.
There's already a good number of changes in the CVS head since the 6.8 release (see either the high level list of changes or the complete ChangeLog), so this is shaping up to be an interesting release, even before considering the modularization changes.
(For those who haven't been following the X.Org development lists, X.Org is planning simultaneous releases of X11R6.9 and X11R7.0, containing the same code, but built and delivered in two very different ways. 6.9 will follow the pattern of previous X11 releases, releasing as one huge monolithic source tree for all the libraries, client programs and servers, configured via Imake with static configuration files for all the supported OS'es. 7.0 will be broken up into separate packages for each library or program, each configured via configure scripts created with the popular GNU autoconf, automake, and libtool tools, with settings for each OS detected at build time.)
As we go into the next phase, we'll be posting soon requests for people to help us prepare for release by building and testing on as many platforms as possible. (We seem to get decent coverage on recent versions of the major Linux & BSD flavors, and on Solaris x86, but drop to a significantly lower number of reports from other OS'es, older releases, and the smaller distros.) We'll probably do this for the 6.9/monolithic tree first, while the autotooling of the 7.0/modular tree gets filled in, and there are changes to the Imake configs which we'll need help verifying on the various platforms. For instance, this release will discourage use of the packages maintained by other people that we've been redistributing in the Xorg source tree - FreeType, FontConfig, etc. As part of this, the default Imake settings have been changed to assume those are already installed on most platforms, and the individual platform config files for certain platforms have been changed to override this when we know those packages aren't typically already installed. But only a few platforms have had this checked and set so far, and there's many left to go. (Of course, you can always override this at compile time, if you know you've already installed one of these packages, and better documenting how to set these is also on the todo list.)
If this has peaked your interest, and you want to learn more on this release, watch the xorg mailing list on freedesktop.org, and check out these links:
- Feature Freeze Reminder and 6.9/7.0 release schedule
- X.Org Modularization Working Group and Modularization Plans
Posted at 03:39PM Jul 04, 2005 by Alan Coopersmith in X11 | Comments[4]
Subscribe!
