lkml.org 
[lkml]   [2003]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:34    [W:0.083 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site