Christoph Lameter wrote:
On Mon, 8 May 2006, Pekka Enberg wrote:
I think it sounds like it's worth it, but I'm not going to really push it.
Sounds good to me. Andrew?
virt_to_page is not cheap on NUMA.
I know. But it was a design assumption when I wrote the slab allocator.
Acutally, it's not cheap on non-NUMA either. And the PageCompound()
check adds an additional branch.
Probably the allocator should be rewritten, without relying on
virt_to_page().
Any proposals how kfree and kmem_cache_free could locate the cachep
pointer? That's the performance critical part.
Right's now it's
<<<
page = vir_to_page(objp)
if (unlikely(PageCompound(page)))
page = (struct page *)page_private(page);
cachep = (struct kmem_cache *)page->lru.next;
>>>
What about:
- switch from power of two kmalloc caches to slighly smaller caches.
- change the kmalloc(PAGE_SIZE) users to get_free_page().
get_free_page() is now fast, too.
- use cachep= *((struct kmem_cache **)(objp & 0xfff))
The result would be a few small restrictions: all objects must start in
the first page of a slab (there are no exceptions on my 2.6.16 system),
and PAGE_SIZE'd caches are very expensive. Replacing the names_cache
with get_free_page is trivial. That leaves the pgd cache.
--
Manfred
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
