Probably a similar speed to removing page mappings with inter-CPU TLB
flushes. But I don't know.
> Anyway, I wouldn't be worried about the low water mark IRQ being acted
> on slowly as much as the high mark. A FIFO overflow would cause missed
> commands.
A FIFO overflow cannot happen in the scheme I've described. If user
space submits a buffer larger than the hardware can handle, that's the
kernel's problem.
Since IRQ delivery timing is not well specified, not instant and implies
some overhead, shouldn't the kernel be avoiding overflow in the first
place by not submitting more than the hardware will handle at a time?
Thus it's only the low watermark which is important, to keep the
hardware busy.
> Though I suppose if the firing of the watermark IRQs could be adjusted
> to be sooner the latency could be compensated for, but the amount of
> compensation required would vary depending on system load.
Provided the kernel always has a command buffer ready to send, the
latency is fixed and is the low watermark interrupt latency (including
variance), if the buffer is sent by DMA. Interrupt latency is proving
quite reliable these days, apparently.
If the buffer has to be spoon-fed then maybe the spoon-feeder would run
as a bottom half. In that case, the watermark may indeed need to be
dynamically adjusted. I don't think it's hard to do that adjustement --
if the FIFO nearly empty when you start a fill, raise the watermark. If
the FIFO is twice as full as that, lower the watermark.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/