Re: proc_misc.c bug

["Randy.Dunlap" <rddunlap@osdl.org>]

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."]