This isn't a bug with the drivers, it's a side effect of the Linux kernel timer resolution. The kernel scheduler (at least, this is my understanding of it) runs once every 1/HZ seconds (HZ is 100 on Intel machines, and 1024 on certain others).
This means that there is a latency of 1/HZ seconds, or 10ms, possible if any thread (or process) gives up control.
This also means that the vertical retrace can't be synced to by waiting for an interrupt; the userspace code that runs in response to that interrupt might be very, very late.
So instead, the drivers busy-wait on the vertical retrace signal. When a retrace is in progress, they return (and glXSwapBuffers finishes).
The only way to change this is to change the kernel timer resolution. Or, change your threading package to be a preemptive one (AKA pthreads) rather than a cooperative one. There's no reason a high CPU utilization in one thread would stop others from running, especially if they're only doing I/O, unless you're using a userspace threading package that can only do cooperative multitasking.