Messages in this thread | | | Date | Fri, 11 Apr 2003 10:29:46 -0700 | From | "Randy.Dunlap" <> | Subject | Re: proc_misc.c bug |
| |
On Thu, 10 Apr 2003 22:41:23 -0700 David Mosberger <davidm@napali.hpl.hp.com> wrote:
| >>>>> 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/
| |