Ikke's Blog

Category: Linux

Feb 17
Python, Cairo, XShape and clocks

Tonight I wrote some little Python application to play around with Cairo (PyCairo that is), and XShape. The result? Something similar to MacSlow's Cairo-Clock, although much more basic.

Application image

You can find the result in my code section.

Just start it in some terminal. Clicking on the clock allows you to move it, clicking it while pressing a shift keys starts resizing mode. When running on top of a terminal/browser/whatever with scrollbars, try to move your pointer close to the clock's circle, inside the area that's normally covered by the clock's window/frame, then use your scrollwheel. As you should notice, the scroll events are not sent to the clock window, but to the underlying window: it's really a circle, not a transparant rectangular window which still catches all events anyway.

Have fun with it!

Edit: there's a little screencast online. Warning: colors look bad, this is caused by the recording software.

Jan 30
Linux kernel drivers

Nice move by the kernel developers.
Now hardware companies got almost no reason at all not to provide Linux drivers for their devices. Especially since "Linux Compatible" starts to become more important everyday.

Jun 16
Regarding string duplication

This entry might bore most of you, upset some others, and could be useful for some. Sorry!!!

Last 3 days I've been reading (in my study pauses ;-)) on code optimalisation (both code speed and memory) and DSO pitfalls (pointers and some samples might follow later).

One of the things I read was a paper by Ulrich Drepper (Glibc guy), where one of the samples was about string duplication (strdup) optimalisation.

I looked into the Glib (no, thats not glibc) code to see how it was handled there, and found a simple, straight-forward, (unoptimized) implementation.
So obviously, I wanted to find out if this could be somewhat optimized. So I started my precious gvim, and made a testcase, which does some (well, a lot of) different duplications, both using g_strdup and my own little implementation.

An overview of what the test code does:

  • Do one simple strdup using g_strdup, and free the result (so the test is "fair", think of relocation time)
  • Copy, print and free a compile-time constant string, a variable string (argv[0]), and an empty string (strlen printed here) to make sure the code works fine
  • In a loop of 10000000 iterations, duplicate a constant string, a variable one (again, argv[0]) and an empty one, and free them

Why always a constant string, a variable one and an empty one? Simply because my implementation tries to handle these cases in the most efficient way ;-)

Here's the result:

nicolas@marslander ~/tmp $ gcc -o my_strdup_test -O2 `pkg-config --cflags --libs glib-2.0` g_strdup_test.c
g_strdup_test.c:9:10: warning: #warning "Using own implementation"
nicolas@marslander ~/tmp $ gcc -o g_strdup_test -O2 `pkg-config --cflags --libs glib-2.0` g_strdup_test.c -DUSE_G_STRDUP
g_strdup_test.c:5:10: warning: #warning "Using g_strdup"
nicolas@marslander ~/tmp $ ./g_strdup_test > /dev/null && echo -e "g_strdup_test:\n==============" && time ./g_strdup_test && ./my_strdup_test > /dev/null && echo -e "my_strdup_test:\n===============" && time ./my_strdup_test
g_strdup_test:
==============
foo = foo
./g_strdup_test = ./g_strdup_test
0 = 0

real    0m9.438s
user    0m8.968s
sys     0m0.064s
my_strdup_test:
===============
foo = foo
./my_strdup_test = ./my_strdup_test
0 = 0

real    0m5.906s
user    0m5.627s
sys     0m0.033s

I know 'time' is not a very good benchmark, but I guess the result is fairly obvious.
This result is +- the average, g_strdup version ranging between 9.4 and 9.6 seconds, mine between 5.8 and 6.1 seconds. This is a 30-40% speed gain, not wasting more memory.

Obviously, not all duplications would become faster. Actually, only the ones of strings which are constant at compile-time. In some applications this can be a major amount of g_strdup calls though.

I should note this "enhancement" is only possible when GCC is used as compiler as it uses some GCC-specific extensions. This is not an issue though, as on other compilers the code won't become slower :-)

The code I used can be found here. I added comments to make some things easier to understand (I hope), but the code is not "clean". A check for GCC should be added etc, but hey, this is just a proof of concept.

I really like these rather low-level optimisation things. They allow a lot of applications to become more efficient without changing the actual app, and low-level code is fun.
I'll read some more about this, and try to blog about interesting papers/techniques/... too, got some things in mind, but lack time now (yeah, those exams).

Luckily the end is in sight, and so is GUADEC :-) Booked my plane some days ago, still awaiting one email about lodging stuff. I'm so glad and thankful I'll be able to be there. Great start of holidays ;-)

Enough now, more algebraics and geometry to learn...

May 31
Ubuntu CD packages

I just passed by some Ebay-like shop, and saw a guy over there selling Ubuntu CD packages, which I guess he got for free from the Shipit program. 3.50

Ikke • LinuxPermalink 11 comments
May 29
SoC, GUADEC and SystemTap

Little update:
1. I got a SoC assignment, at Gentoo. I'll be (actually I am) working on Gentoo's NetworkManager backend and integration into the distribution, next to more general NetworkManager hacking (although some people seem to dislike that somehow :|).
2. I might be able to come to GUADEC, jay!
3. Experimented with SystemTap today. After seeing the DTrace demos at Fosem06, I was fairly impressed. Systemtap is no DTrace-for-Linux yet, but I the scripts I was able to run were pretty promissing.

Little HOWTO (on Gentoo, but should work on other distributions too):
$ (cd into some project folder, I used ~/Projects/systemtap)
$ mkdir elfutils && cd elfutils
$ wget ftp://sources.redhat.com/pub/systemtap/elfutils/elfutils-0.120.tar.gz ftp://sources.redhat.com/pub/systemtap/elfutils/elfutils-portability.patch
$ tar -zxf elfutils-0.120.tar.gz && cd elfutils-0.120
$ cat ../elfutils-portability.patch | patch -p1
$ cd ..
$ cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/systemtap login
(pass is "anoncvs", no quotes)
$ cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/systemtap co systemtap
$ cd src
$ ./configure --prefix=/path/where/you/want/the/stuff --with-elfutils=/path/to/patched/elfutils
I used ~/Projects/inst as prefix (expanded), and ~/Projects/systemtap/elfutils/elfutils-0.120 as elfutils path
$ make
make failed for me (GCC4.1.1) due to usage of -Werror in elfutils. I had to add a -Wno-error in elfutils/elfutils-0.120/src/Makefile.am on the appropriate place (you should be able to do that yourself).
$ make install

Now we need a kernel with debug info, and kprobe support.
$ cd /usr/src/linux
$ make clean
$ make menuconfig
Configure the kernel like you would normally. Make sure you change the "Local version" under "General Setup". I added -dbg to the string I already got there ("-ck1-ikke2-dbg"), so your "normal" kernel modules won't be overwritten.
Then you need these options. This list might not be complete though:
- Instrumentation Support -> Kprobes
- Kernel hacking -> Compile the kernel with debug info
- Kernel hacking -> Compile the kernel with frame pointers (this might not be necessary)
$ make
$ make modules_install
The generated kernel will be big:
# du -sh /lib/modules/2.6.16.18-ck1-ikke2-dbg/ /usr/src/linux/vmlinux
21M /lib/modules/2.6.16.18-ck1-ikke2-dbg/
36M /usr/src/linux/vmlinux
and compilation (actually, linking) might take longer than normally. Used diskspace will be much higher too.

$ cp /usr/src/linux/vmlinux /lib/modules/2.6.18-ck1-ikke2-dbg/
(adjust paths!)

Now install the kernel like you normally would. I didn't put it as my default kernel in grub.conf though.

When you're done, reboot inside the new kernel. I booted into single user mode (by appending "1" to the GRUB line), just to be on the safe side.
Log in as your normal user on the console.

$ cd Projects/systemtap/src/examples/small_demos/
$ ~/Projects/inst/bin/stap top.stp -v
stap will show what it's doing. In the end, sudo will be called to insmod the generated module. Enter your password. Make sure the user is allowed to use sudo with the specific program (run with one more -v to see the specific call).

When it says everything's up and running, try switching console, type in some characters,... And see what system calls these actions generate.
As you're in single user mode, you can only use one tty. Run the stap instance in a screen session to get rid of this ;-)

Whe done, press ^C to quit. You can play around with some other sample scripts too, or try to write one yourself. I didnt manage to get some of the scipts working on my system yet though. Didn't think too much about it either :-)

Thats it, have fun!

4. Started reading "Linux Device Drivers, 3th edition", at chapter 6 now. Cool stuff, concurrency and locking (ch5) seems to be a fairly difficult issue. It is in userspace (threading), seems to be even harder in kernel space imho.

5. First exam tomorrow, "Rights of Intellectual Property". Wish me luck ;-)

<< Previous Page :: Next Page >>

Categories

Who's Online?

  • Guest Users: 121

Misc

XML Feeds

What is RSS?