![]() | |||||||||||||
Messages in this thread |
Dipankar Sarma wrote: > > On Wed, Dec 04, 2002 at 11:34:35AM -0800, Andrew Morton wrote: > > > +/* Use these with kmalloc_percpu */ > > > +#define get_cpu_ptr(ptr) per_cpu_ptr(ptr, get_cpu()) > > > +#define put_cpu_ptr(ptr) put_cpu() > > > > These names sound very much like get_cpu_var() and put_cpu_var(), > > yet they are using a quite different subsystem. It would be good > > to choose something more distinct. Not that I can think of anything > > at present ;) > > Well, they are similar, aren't they ? get_cpu_ptr() can just be thought > of as the dynamic twin of get_cpu_var(). So, in that sense it seems ok > to me. hm. spose so. > > > > If we were to remove the percpu_interlaced_alloc() leg here, we'd > > have a nice, simple per-cpu kmalloc implementation. > > > > Could you please explain what all the other code is there for? > > The interlaced allocator allows you to save space when kmalloc_percpu() > is used to allocate small objects. That is done by interlacing each > CPU's copy of the objects just like the static per-cpu data area. > Where in the kernel is such a large number of 4-, 8- or 16-byte objects being used? The slab allocator will support caches right down to 1024 x 4-byte objects per page. Why is that not appropriate? If it is for locality-of-reference between individual objects then where in the kernel is this required, and are performance measurements available? It is very unusual to have objects which are so small, and a better design would be to obtain the locality of reference by aggregating the data into an array or structure. Sorry, but you have what is basically a brand new allocator in there, and we need a very good reason for including it. I'd like to know what that reason is, please. - 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 12:31 [W:0.335 / U:0.090 seconds] ©2003-2008 Jasper Spaans | |||||||||||||