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/