The most peculiar thing about this code is that if it starts out with a
latency timer set to 10 it will leave it alone, but if it was set to 9 it gets
wound all the way up to 255.
>latency prediction for the whole system. Setting a large value for a
>device latency timer in low level drivers is kind of ego-mania and is
>highly wrong and broken.
10 PCI clocks is fairly short as bursts go. It's not all that unreasonable
for the driver to try to enforce some sort of minimum burst length because
some devices need this either to get reasonable performance or to work at all.
A device is allowed to have its latency timer fixed (in hardware) at a value
up to 16. Also, you can have unavoidable latencies of up to about 16 ticks
due to read accesses to slow targets. For old (pre PCI 2.1) devices this can
be even longer.
>good pci timer value to PCI devices, actual PCI BUS latency is probably
>often bad tuned for heavily loaded systems.
>For such systems, a driver that sets the PCI latency timer of a device to
>255 has every chance to make things worse.
It depends on what you're worried about. A higher timer value will increase
throughput but at the expense of bus latency. If the timer is set too low
so that bursting rarely occurs then the bus bandwidth is greatly reduced and
may not even be able to keep up with some hardware. Conversely if the timer
is too large then all other devices are kept waiting -- and there's a tendency
for the people looking after these other devices to try to compensate by
winding up _their_ latency timer as well, to try to increase their share of
the bus bandwidth.
In theory, given information about what max_lat and min_gnt each device would
like, the PCI support code ought to be able to try to calculate "ideal"
latency timer values for all devices. This would be an interesting thing for
somebody to try.
p.
-
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/