Messages in this thread | | | Date | Tue, 15 Apr 2008 14:27:13 -0700 | From | Mike Travis <> | Subject | Re: [bug] SLUB + mm/slab.c boot crash in -rc9 |
| |
Ingo Molnar wrote: > * Christoph Lameter <clameter@sgi.com> wrote: > >> On Tue, 15 Apr 2008, Ingo Molnar wrote: >> >>> and the bug pattern seems to be memory corruption - not memory >>> exhaustion. >> SLUB does not do a memory allocation where it fails here but simply >> accesses per cpu information that is expected to be already zeroed. >> >>> i.e. we allocated RAM but it got corrupted after allocation. >> In some situations we are screwing up the per cpu data handling on 32 >> bit x86? Adding Mike. This looks like the per cpu area overlaps with >> something else? > > yep, that was my other theory - and i doubled CONFIG_NR_CPUS to reduce > that chance. > > in hindsight ... that wont save us from any overlap, right? > > what's the best way to artificially increase the size of the allocated > per cpu area? (say double it) > > Ingo
I don't know that there is a boot option. If modules are defined it adds an extra 8k. The size is defined in include/linux/percpu.h (PERCPU_ENOUGH_ROOM).
Otherwise define a really large per_cpu variable...?
-Mike
| |