Ouch? It is supposed to be that way. Consider:
A high-priority task issues a disk read - and blocks. Some
lower-priority process gets the cpu. But then the disk io finishes
way before the low-priority process used up its timeslice.
The kernel gets an interrupt from the disk controller because
of that. Perhaps the block device issues some more requests,
then time comes to return to user space. The higher priority task
is now ready to run because its IO completed. So of course
it is preferred over that low-priority thing. In other words,
the low-priority task got preempted, this time by a disk
interrupt.
The same thing happens whan high-priority tasks waits for
other kinds of io, such as network, serial, and so on.
I am sure you wouldn't want it any other way. Not
using the opportunity to switch task immediately after an io
completion interrupt would kill latency completely.
Helge Hafting
-
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/