On Fri, 15 Jan 2010, Lee Schermerhorn wrote: > > The following patch makes init_kmem_cache_nodes assume 0 > > for statically allocated kmem_cache structures even after > > boot is complete. > > I believe that on Alex's platform, the kernel will get loaded into "node > 2", the hardware interleaved pseudo-node, because it's located at phys > 0..., and has sufficient space. So, this might not work here. Hmm. thats gets us into some strange issues. > > Index: linux-2.6/mm/slub.c > > =================================================================== > > --- linux-2.6.orig/mm/slub.c 2010-01-15 14:02:54.000000000 -0600 > > +++ linux-2.6/mm/slub.c 2010-01-15 14:04:47.000000000 -0600 > > @@ -2176,7 +2176,8 @@ static int init_kmem_cache_nodes(struct > > int node; > > int local_node; > > > > - if (slab_state >= UP) > > + if (slab_state >= UP && > > > > s < kmalloc_caches && > > + s > kmalloc_caches + KMALLOC_CACHES) > > ??? can this ever be so? for positive KMALLOC_CACHES, I mean... An allocated kmem_cache structure is definitely not in the range of the kmalloc_caches array. This is basically checking if s is pointing to the static kmalloc array. -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |