Monthly Archives: September 2008

moving to kernel.org

I've finally got my kernel tree up on kernel.org. It took a couple of weeks to get an account, then a couple of weeks to find the time to worry about it.

http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=shortlog;h=drm-intel-next
git clone git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel

This should be the place where all of our future "ready for upstream" work goes. So, for example, if you're looking to test GEM, grab these branches:

kernel: drm-intel-next
libdrm: master
xf86-video-intel: master
mesa: master

If you're looking to test dri2, it's a little more work. Grab these:
kernel: drm-intel-next
libdrm: master
dri2proto: master
xserver: master (then edit hw/xfree86/Makefile.am to uncomment dri2)
xf86-video-intel: dri2
mesa: master

moving to kernel.org

I've finally got my kernel tree up on kernel.org. It took a couple of weeks to get an account, then a couple of weeks to find the time to worry about it.

http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=shortlog;h=drm-intel-next
git clone git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel

This should be the place where all of our future "ready for upstream" work goes. So, for example, if you're looking to test GEM, grab these branches:

kernel: drm-intel-next
libdrm: master
xf86-video-intel: master
mesa: master

If you're looking to test dri2, it's a little more work. Grab these:
kernel: drm-intel-next
libdrm: master
dri2proto: master
xserver: master (then edit hw/xfree86/Makefile.am to uncomment dri2)
xf86-video-intel: dri2
mesa: master

Announcing EuroBSDCon 2008

It took a while, but registration for EuroBSDCon 2008 is now open!

As usual, there are many interesting talks and tutorials. Life was again "interesting" for the program committee!

For FreeBSD developers, there will be the usual by-invitation developer summit two days before the conference.

I would like to note that this will be the first non-FOSDEM conference I'm attending this year with only marginal impact on my carbon footprint.

I'm taking the train!

FreeBSD/mips updated

Here's an update in status to the FreeBSD/mips tree. David O'Brien has been working through issues one at a time to get things building, primarily getting gcc support merged in. After learning from David that more patches were needed than were in my blog, I spent some time collapsing changes from p4 into the main tree. I've updated my patches, and confirmed they work.First, you can find the patches from my FreeBSD drop box. These patches are 42k right now. This is from my tree that I pulled at revision 183198, taken at 3:30pm MDT September 19th, 2008, for the nit-pickers out there. At this level, I'm able to apply the patch, do a buildworld and all the kernels except SENTRY5 build. To build things:
% svn update% fetch http://people.freebsd.org/~imp/MipsSvn.diff% patch -p0 < MipsSvn.diff% setenv TARGET mips% setenv MAKEOBJDIRPREFIX /tmp/$LOGNAME/obj% make buildworld% make buildkernel KERNCONF={ADM5120,IDT,MALTA,QEMU}
I've just done the build testing at this point. Stay tuned in the coming days for how to setup a qemu or gxemul image and how to run this in emulated. I hope to get instructions for how to deal with real hardware a little bit after that. Right now the ADM5120 kernels are a little too big for the hardware that I have and it will take some time to sort out.Hopefully we'll have these last 42k of patches into the tree in the coming weeks. I'll keep everybody posted. There are some additional fixes in p4 as well on top of this which I'm still sorting out, but those should be going in as well.

FreeBSD/mips updated

Here's an update in status to the FreeBSD/mips tree. David O'Brien has been working through issues one at a time to get things building, primarily getting gcc support merged in. After learning from David that more patches were needed than were in my blog, I spent some time collapsing changes from p4 into the main tree. I've updated my patches, and confirmed they work.

First, you can find the patches from my FreeBSD drop box. These patches are 42k right now. This is from my tree that I pulled at revision 183198, taken at 3:30pm MDT September 19th, 2008, for the nit-pickers out there. At this level, I'm able to apply the patch, do a buildworld and all the kernels except SENTRY5 build. To build things:

% svn update
% fetch http://people.freebsd.org/~imp/MipsSvn.diff
% patch -p0 < MipsSvn.diff
% setenv TARGET mips
% setenv MAKEOBJDIRPREFIX /tmp/$LOGNAME/obj
% make buildworld
% make buildkernel KERNCONF={ADM5120,IDT,MALTA,QEMU}


I've just done the build testing at this point. Stay tuned in the coming days for how to setup a qemu or gxemul image and how to run this in emulated. I hope to get instructions for how to deal with real hardware a little bit after that. Right now the ADM5120 kernels are a little too big for the hardware that I have and it will take some time to sort out.

Hopefully we'll have these last 42k of patches into the tree in the coming weeks. I'll keep everybody posted. There are some additional fixes in p4 as well on top of this which I'm still sorting out, but those should be going in as well.

Timed measurements with pmcstat(8)

Every once in a while I get email asking for an option to pmcstat(8) that would allow hardware events to be measured for a specified time interval.

The good news is: pmcstat(8) already supports timed measurements — using /bin/sleep.

Here is how you would do it:

  • Timed system sampling would be done in the following manner:

    % pmcstat -S instructions -O logfile /bin/sleep 42

    This invocation allocates a system-scope sampling PMC (-S) and profiles the whole system while /bin/sleep executes, i.e., for 42 seconds.

  • Timed measurements on groups of processes are performed in a similar fashion:

    % pmcstat -d -p dc-misses -t '1234' /bin/sleep 24

    This invocation would allocate a process-scope counting PMC (-p) that counts data cache misses, attach it (-t) to the process with pid 1234 and its descendants (-d), and count for 24 seconds.

    Note that the '-t' option also takes regular expressions, so you don't need to know process ids beforehand. To count instructions executed by processes named 'httpd' for an hour you would use:

    % pmcstat -p instructions -t 'httpd' /bin/sleep 3600

The "Unix way" uses small tools, each of which does a defined task reasonably well and which are combined to perform more complex tasks. In the examples above, /bin/sleep manages time intervals and pmcstat(8) manages PMC based measurements.

When you combine them, voilà, you get timed PMC based measurements.

Timed measurements with pmcstat(8)

Every once in a while I get email asking for an option to pmcstat(8) that would allow hardware events to be measured for a specified time interval.

The good news is: pmcstat(8) already supports timed measurements — using /bin/sleep.

Here is how you would do it:

  • Timed system sampling would be done in the following manner:

    % pmcstat -S instructions -O logfile /bin/sleep 42

    This invocation allocates a system-scope sampling PMC (-S) and profiles the whole system while /bin/sleep executes, i.e., for 42 seconds.

  • Timed measurements on groups of processes are performed in a similar fashion:

    % pmcstat -d -p dc-misses -t '1234' /bin/sleep 24

    This invocation would allocate a process-scope counting PMC (-p) that counts data cache misses, attach it (-t) to the process with pid 1234 and its descendants (-d), and count for 24 seconds.

    Note that the '-t' option also takes regular expressions, so you don't need to know process ids beforehand. To count instructions executed by processes named 'httpd' for an hour you would use:

    % pmcstat -p instructions -t 'httpd' /bin/sleep 3600

The "Unix way" uses small tools, each of which does a defined task reasonably well and which are combined to perform more complex tasks. In the examples above, /bin/sleep manages time intervals and pmcstat(8) manages PMC based measurements.

When you combine them, voilà, you get timed PMC based measurements.

Renumbering: why I love Unix

For various reasons, I had to renumber the machine this blog (and a number of other things) run on. A pain, of course, but FreeBSD makes it fairly easy.

First, I shut down all the jails using /etc/rc.d/jail stop. I probably could have renumbered the jails too, but it was easier just to restart them.

I removed all IP addresses except for the one I was talking to, and added the new addresses:

# ifconfig hme0 89.106.240.243 -alias
# ifconfig hme0 89.106.240.244 -alias

# ...

# ifconfig hme0 alias 89.106.240.146/28
# ifconfig hme0 alias 89.106.240.147/32
# ifconfig hme0 alias 89.106.240.148/32

# ...

I also put the new configuration in /etc/rc.conf so things will keep working after the next reboot.

After verifying that I could ping the new addresses from the outside (ie: that the router behaved as expected), I used a trivial little script to fix the routing table:

#!/bin/sh
route delete default
ifconfig hme0 89.106.240.242 -alias
route add default 89.106.240.145
shutdown -r +10

The shutdown -r +10 is just for insurance. :-)

Of course, it just worked!

Then it was just a matter of updating DNS and restarting some services which were bound to the old address only instead of INADDR_ANY.

Unix rules!

Csup status

Finally, I have been able to resolve all current known issues with cvsmode support in csup. I just sent out a new announcement with the patch, and I hope to get some more testing and perhaps some reviews soon, but it is a big patch and few people are familiar with the code base.

Remaining issues with the patch is support for using the status file when reading (but this is not critical at all), as well as rsync support (which is only significant for a few files in the freebsd repository).

I hope as many as possible are able to test it:

http://people.freebsd.org/~lulf/patches/csup/csup_09_16_2008.diff

linimon’s freebsd blog

I’m continuing to do some maintenance on the weekly PR emails, and the new prototype PR pages. The former are having their formatting fixed up and the boilerplate removed. The latter has been rewritten to group the reports by commnity of interest, and has also added PRs that have been modified in the last day/week/month; PR count by assignee; and latest commit by assignee.

In addition, the main pointyhat erorrlog page is now much more readable. A bugfix there has also helped portsmon get back up to date.

Finally, I’ve completely rewritten my home page on freefall, so that you can find the various projects that I am working on (including the above), the presentations that I have done at various BSDCan and EuroBSDCon conferences.

taste of success

As part of the work we're doing for Moblin, I got our head trees in shape for GL compositing on GEM. We had a nice demo of the technology at XDS from krh, and today I got the same setup working: glxgears and totem on a cube all playing nicely together. It feels like things are finally coming together, and we'll be ready to support this stuff in releases soon, even if it won't be at the end of this release cycle.

All the code's in master, and available to test. The usual warnings about master apply, and just to show how serious we are about our in-development code, among the known issues are:

Can't do UXA (and therefore DRI2) with tiling.
It's kind of hard to teach X about tiled buffers. NVIDIA went with wrapping all pixel access from libfb to produce libwfb. Our plan is to return to GTT-managed access of buffers in the X Server so we don't have to teach it about this -- we keep the nice write-combined performance we're used to with framebuffer access, though we also suffer from painful read performance we're used to if we have fallbacks that read (See also: Render gradients and convolutions).

2D performance has tanked when you use UXA.
If you fallback on front buffer rendering with the X Server, GEM goes wild with cache flushing because the X Server isn't telling it just what memory it touched, yet we're telling GEM that the results need to land in the front buffer "soon". This means that compositing is fast, but non-composited isn't if you run emacs or gitk anything else that causes fallbacks. There are a couple of potential fixes for this, but the current plan is to avoid it using GTT mapping, which resolves the coherency issue.

Long term, we're going to be adding support for telling GEM what pages we touched after the fact (or maybe use fault-based clflushing) for OpenGL, and at that point we may reconsider how X maps its buffers.

3D performance has tanked in some cases
Haven't debugged this one, and it's next on the list. Can't reproduce on the test systems here.

Applications hang on to a lot of buffer objects
In TTM we would allocate giant buffer objects and then suballocate out of them, because allocation performance was so slow. This meant that userland had to pay attention to a lot of fencing issues (and you had to expose the idea of a fence) so that you could know which pieces were still used.

We went with a simpler model for GEM, where the userland caches buffer objects of similar size, and reuses them when the kernel tells us they're no longer used by the GPU. By returning "freed" buffers to the cache, we get wonderful performance when an app is running flat out and allocating and freeing buffers like mad. However, as we think about cairo moving to a GL backend, and all your apps sitting waiting for input hanging onto these cached buffers, the memory usage is likely to become an issue. They're pageable, but that's slow and we're looking at systems with limited memory+swap anyway. Instead, we need to free buffers when they're not serving any use in the cache. One way we're thinking about is on allocate, when a cached buffer is "really old" (seconds), actually free it.

That still leaves some excess memory laying around when an app does some rendering and then stops for input. The long-term solution would be for userland to tell the kernel when it wasn't going to actively use a buffer and the contents could be thrown out. Then, in the memory pressure callback from the kernel, we can throw out cached buffers and nuke mappings, and userland has to allocate new ones when it needs.

taste of success

As part of the work we're doing for Moblin, I got our head trees in shape for GL compositing on GEM. We had a nice demo of the technology at XDS from krh, and today I got the same setup working: glxgears and totem on a cube all playing nicely together. It feels like things are finally coming together, and we'll be ready to support this stuff in releases soon, even if it won't be at the end of this release cycle.

All the code's in master, and available to test. The usual warnings about master apply, and just to show how serious we are about our in-development code, among the known issues are:

Can't do UXA (and therefore DRI2) with tiling.
It's kind of hard to teach X about tiled buffers. NVIDIA went with wrapping all pixel access from libfb to produce libwfb. Our plan is to return to GTT-managed access of buffers in the X Server so we don't have to teach it about this -- we keep the nice write-combined performance we're used to with framebuffer access, though we also suffer from painful read performance we're used to if we have fallbacks that read (See also: Render gradients and convolutions).

2D performance has tanked when you use UXA.
If you fallback on front buffer rendering with the X Server, GEM goes wild with cache flushing because the X Server isn't telling it just what memory it touched, yet we're telling GEM that the results need to land in the front buffer "soon". This means that compositing is fast, but non-composited isn't if you run emacs or gitk anything else that causes fallbacks. There are a couple of potential fixes for this, but the current plan is to avoid it using GTT mapping, which resolves the coherency issue.

Long term, we're going to be adding support for telling GEM what pages we touched after the fact (or maybe use fault-based clflushing) for OpenGL, and at that point we may reconsider how X maps its buffers.

3D performance has tanked in some cases
Haven't debugged this one, and it's next on the list. Can't reproduce on the test systems here.

Applications hang on to a lot of buffer objects
In TTM we would allocate giant buffer objects and then suballocate out of them, because allocation performance was so slow. This meant that userland had to pay attention to a lot of fencing issues (and you had to expose the idea of a fence) so that you could know which pieces were still used.

We went with a simpler model for GEM, where the userland caches buffer objects of similar size, and reuses them when the kernel tells us they're no longer used by the GPU. By returning "freed" buffers to the cache, we get wonderful performance when an app is running flat out and allocating and freeing buffers like mad. However, as we think about cairo moving to a GL backend, and all your apps sitting waiting for input hanging onto these cached buffers, the memory usage is likely to become an issue. They're pageable, but that's slow and we're looking at systems with limited memory+swap anyway. Instead, we need to free buffers when they're not serving any use in the cache. One way we're thinking about is on allocate, when a cached buffer is "really old" (seconds), actually free it.

That still leaves some excess memory laying around when an app does some rendering and then stops for input. The long-term solution would be for userland to tell the kernel when it wasn't going to actively use a buffer and the contents could be thrown out. Then, in the memory pressure callback from the kernel, we can throw out cached buffers and nuke mappings, and userland has to allocate new ones when it needs.

Three days in Milan

This morning I had to go to the US Consulate in Milan to get the visa. I’m in Milan since Wednesday, hosted by Max Stucchi.

On Wednesday night, GUFIPizza took place: it’s the monthly meeting of the GUFI (FreeBSD Italian Users Group) members who live near Milan. Since I was there, other members who don’t usually show up showed up ( ;) ), Cris, _Oity_ and satu among the others. It was fun because I didn’t see some of them since 2 or even 4 years. We proved that geeks cannot speak about anything but computers when they meet, even when they don’t want to. That night, the main topic was Facebook. Anyway.

Yesterday I went to NewOldCamera and bought two Voigtlander-Cosina rings to mount my Leica screwmount lenses on my Leica M (actually CL) body and I even bought a Billingham L2 bag. It’s soooo well made. =)

Today is a raining day in Milan and I have neither an umbrella nor a jacket… :|

linimon’s freebsd blog

I finally got around to updating these after having let them gather dust for a while. These include bar charts showing the time periods that various releases were being worked on (QA = Quality Assurance) and were supported by the FreeBSD security team. The dates for 6.4, 7.1, and beyond are all “best-guess”.

I find the graphs much easier to understand than the text-format descriptions in various emails.

The data are up at schedule.html.

simon’s blog

I wrote a bit about one of my current projects for the FreeBSD Status report, unfortunatly due to some mixup it didn’t get included, so I’m posting the text here instead:

Recently NetApp donated one of their Filer storage systems and Sentex donated hosting of it with the FreeBSD Foundation helping with various administrative tasks. See the FreeBSD Foundation July 2008 Newsletter for details of the donation.As of this writing around 1 TB of data has been transfered to the off-site storage system and critical systems are being set up for periodic backup as time permits. The 1 TB includes the FreeBSD ftp-archive containing old FreeBSD releases which is being extra backed up to avoid loosing the history data for the FreeBSD project.

The actual backups are being done with rsync over ssh glued together by some custom scripts. As I’m not that creative with naming, the “system” is called qsbp or “Q Simple Backup Push”. File system snapshots are being used to preserve old data while still allowing a relativly simple system to be used.

On behalf of the the FreeBSD Admins Team, I would like to thank NetApp, Sentex, and the FreeBSD Foundation for making this possible.