Re: [PATCH] SLAB - have index_of bug at compile time.

[Steven Rostedt]

On Mon, 26 Dec 2005, Manfred Spraul wrote:

> Steven wrote:
>
> >So I'm going through ever line of code and examining it
> >thoroughly, when I find something that could be improved
> >
> Try to find a kfree implementation that doesn't need virt_to_page().
> This is a big restriction of the current implementation: It's in the hot
> path, but the operation is only fast on simple systems, not on numa
> systems without a big memory map.
> And it makes it impossible to use vmalloc memory as the basis for slabs,
> or to use slab for io memory.
>

Unfortunately, that virt_to_page helps make kmalloc and kfree more
efficient.  Since it allows the use of the mem_map pages that map to the
used memory to be used for storing information about the slab.

So removing virt_to_page means you need to store the information relative
to the memory that is mapped.  Thus you need to allocate more than is
needed.

Your question refers to only kfree, which would not really be that
difficult to remove the virt_to_page, since that would just need the extra
memory _for each allocation_.  But then you mention vmalloc and numa,
where it is the generic use of virt_to_page through out slab.c that is the
issue.  I counted 14 direct uses of virt_to_page in slab.c (2.6.15-rc5).
Now you need to find a way to store the information of the off slab
descriptors and for slabs that are more than one page.

Changing the use of virt_to_page would probably hurt those that can use
it, and the changes would not be accepted because of that.  Unless you can
keep the same speed and memory efficiency of those "simple systems".

Now, maybe NUMA and vmalloc might be a good reason to start a new
allocation system along side of slab?

-- Steve

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/