Messages in this thread | | | From | David Mosberger <> | Date | Thu, 10 Apr 2003 22:41:23 -0700 | Subject | Re: proc_misc.c bug |
| |
>>>>> 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.
--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/
| |