It's a recurring problem with the low-latency patch. Basically:
restart:
spin_lock(some_lock);
for (lots of data) {
if (current->need_resched) {
spin_unlock(some_lock);
schedule();
goto restart;
}
if (something_which_is_often_true)
continue();
other_stuff();
}
If there is a realtime task which wants to be scheduled at,
say, one kilohertz, and the execution of that loop takes
more than one millisecond before it actually hits other_stuff()
and does any actual work, we make no progress at all, and we lock
up until the 1 kHz scheduling pressure is stopped.
In the 2.4.15-pre low-latency patch this can happen if we're
running fsync_dev(devA) and there are heaps of buffers for
devB on a list.
It's not a problem in your kernel ;)
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/