| >>>>> On Thu, 10 Apr 2003 22:01:43 -0700 (PDT), "Randy.Dunlap" <rddunlap@osdl.org> said:
|
| 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.
For kmalloc() failing, do you mean the first (large) kmalloc() or the
repeated ones that grow in size each time?
I would think that just doing one big kmalloc up front is desireable
to repeated ones...if the first one does a decent estimate of its max
size. I just don't know how likely that is.
--
~Randy ['tangent' is not a verb...unless you believe that
"in English any noun can be verbed."]
-
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/