Randy> OK, I've looked at it and concluded that it's not bad the way
Randy> it is (after David's patch is applied). However, that really
Randy> depends on whether the static NR_CPUS is well-tuned or not.
Randy> If it's not tuned, then modifying the output to use the
Randy> iterative seq_file methods would make sense. But if it's not
Randy> tuned, someone is (usually) wasting lots of memory anyway.
Randy> [snip...]
Randy> Does someone want to disagree now? go ahead...i'm listening.
Randy> Maybe the reason to modify it is that NR_CPUS is not a good
Randy> approximation/hint/clue.
Wouldn't the kmalloc() likely fail in fragmented conditions? Also,
I'm wondering whether there is such a thing as "well-tuned" in this
case. For example, in the extreme case of the SGI SN2 machine, each
CPU could in theory have up to 256 interrupt sources (OK, perhaps it's
only 256 interrupts per 2 CPUs, but it's still a lot of interrupts to
go around ;-). OTOH, most ia64 machines out there have less than 256
interrupt per _system_. That's a large variation.
--david
-
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/