NAPI performance - a weighty matter
NAPI performance - a weighty matter
Posted Jun 16, 2005 9:13 UTC (Thu) by Duncan (guest, #6647)Parent article: NAPI performance - a weighty matter
> The quota value should not also be the threshold
> at which drivers return to interrupt-driven mode.
As soon as I saw that initially described earlier in the article, I /knew/
it was going to cause issues. I'm not a C programmer, yet even /I/ can
see that. Virtually /everything/ from common HVAC thermostats, to
filesystem cache mechanisms, to, one would /expect/, network interface
quotas, works with a high value that triggers the switch into "high
activity" mode, after which it STAYS in the new mode until the sampled
measure falls below the low value (which is somewhere below the high
value), at which point the system switches back to "low activity" mode.
Failure to have such a lo/hi range by using a single threshold value
ALWAYS triggers inefficient bouncing, for /some/ range of possible values,
or the threshold value wouldn't be needed at all as a single mode would be
all that was required. Simple logic, demonstrated in practice over and
over again, in both the real and virtual world.
<shrug> I guess this is demonstration of the open source adage that all
bugs (and their solutions) are shallow to /somebody/, and an open source
solution maximizes the possibility that said "somebody" will be exposed to
the issue.
OTOH, it's likely only clear to me due to the excellent explanation here
in LWN, which of course the original implementors didn't have the
privilege of seeing, since they were writing the code upon which the
explanation was based. <g>
Duncan