Linux 2.6.33

Stuff I think is interesting in this release:

• Nouveau: This is still premature, and not of much use until the supported features are a super set of those the proprietary drivers provide. (In particular 3d support, and video acceleration). However now that it's been accepted into staging, one can hope that work on this feature will accelerate.
  
• Recvmmsg(): Vectored system calls are always interesting, particularly when doing things on a massive scale. This looks to the first of many networking system calls to be vectorized, allowing for even greater throughput for services with high connection/datagram counts.
• Nintendo/Wii drivers: The more mainstream the hacking of common computer hardware gets the better. Need I say more?
• Reiserfs de-BKLification: This sounds promising. Reiserfs has fallen by the wayside since Ext4 came out. The presence of undesirable locking on SMP machines will not help that. With reiser4 nowhere to be seen, reiserfs needs tweaks such as this to remain competitive.

2010 Courses at Uni

My courses for 2010!

SPAN1001 - Introduction to Spanish I	Undergraduate	03/31/2010
COMP2410 - Networked Info Systems	Undergraduate	03/31/2010
MATH2301 - Games, Graphs & Machines	Undergraduate	03/31/2010
MATH3062 - Fractal Geometry & Chaos Dynam	Undergraduate	03/31/2010

SPAN1002 - Introduction to Spanish II	Undergraduate	08/31/2010
ENGN2221 - System Dynamics	Undergraduate	08/31/2010
MATH3301 - Number Th & Cryptography	Undergraduate	08/31/2010
ENGN3223 - Control Systems	Undergraduate	08/31/2010

SIGALRM and the GIL

had some weird lag issues in nethogs2. i was firing setitimer SIGALRMs to keep things in check, every 0.25s. but strangely some alarms would arrive 6s or more apart...

DEBUG:nethogs2(134):Alarm triggered at 1265561284.348955
INFO:proctab.py(108):Unknown process: Connection(local=('192.168.0.1', 520), remote=('192.168.1.255', 520), family=2, protocol=17)
DEBUG:nethogs2(134):Alarm triggered at 1265561293.166447

which is HIGHLY bizarre, as the OS does this shit, and signals date back so far that you don't fuck with them. they arrive, on time, no excuses.

so i ran python profiler to see wtf is going on:

matt@stanley:/media/data/source/anacrolix/projects/nethogs2$ sudo python -m cProfile -s cumulative ./nethogs2

and i get this

347158 function calls (347141 primitive calls) in 26.807 CPU seconds

all dandy until i see this in the printout:

12 24.737 2.061 24.743 2.062 {_pcap.pcapObject_dispatch}

a C function is using up 90% of my time, LOCKING OUT the signal handling!!

it turns out the call to pcap_dispatch is blocking, and i suspect it was taking the GIL with it. i'd also guess that signals are delivered to your python callback, only if the GIL can be claimed. changed the timeout from blocking to 1ms... problem fixed.