On Wed, 2003-11-05 at 13:16, Theodore Ts'o wrote: > On Wed, Nov 05, 2003 at 10:18:38AM -0500, Martin Hicks wrote: > > > > ext2 & ext3 lists, > > > > Attatched is a patch that allows ext2 and ext3 to link correctly when > > the kernel is configured with a large NR_CPUS. We do have an immediate > > need for this patch. > > That's run correctly, I assume.... the kernel doesn't link because there is some magic to complain about kmalloc()ing more than 128kB. > > > Any opinions on this? The per-cpu lists are causing the kmalloc to fail > > due to allocating more than the max. > > vmalloc()'s are not free. They burn kmap address space, TLB entries, > etc. How many CPU's are necessary before we run into problems, > anyway? > I agree that using vmalloc() is probably not the best solution. According to my calculations the magic number of processors is just under 300. > I'd be much happier if there was a kvmalloc() call which resolved to > either kmalloc() or vmalloc() depending on how insane the number of > CPU's were, or if kvmalloc() programmatically made the determination > at runtime, and kvfree() checked the address to determine whether it > was a kmalloc()-returned address or a vmalloc()-returned address, and > called kfree() or vfree() as appropriate. Using Andreas idea will work for more than 512p, but I don't think it will work for 1024p. The sizeof(percpu_counter) on ia64 is 64k + a small amount of overhead. I think we can fix this problem for my current situation, but those percpu_counters are going to cause problems due to their dependence on NR_CPUS. I looked at the super.c briefly, but I still don't understand what those counters do. Is there any possibility of getting rid of the percpu_counters from the ext[23] superblock? mh -- Martin Hicks Wild Open Source Inc. mort@xxxxxxxxxxxxxxxxxx 613-266-2296 _______________________________________________ Ext3-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/ext3-users
