[lkml]   [2006]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] fs: fcntl_setlease defies lease_init assumptions
    On Tue, 9 May 2006, Manfred Spraul wrote:
    > 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->;
    > >>>
    > 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))

    I think you mean

    static inline struct kmem_cache *slab_get_cache(const void *obj)
    struct kmem_cache **p = (void *)((unsigned long) obj & ~(PAGE_SIZE-1));
    return *p;

    On Tue, 9 May 2006, Manfred Spraul wrote:
    > 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.

    Your plan makes sense for slabs that have slab management structures
    embedded within. We already have enough free space there for one pointer
    due to

    colour_off += cachep->slab_size;

    in the alloc_slabmgmt() function, I think. Are you planning to kill
    external slab management allocation completely by switching to
    get_free_pages() for those cases? I'd much rather make the switch to page
    allocator under the hood so kmalloc(PAGE_SIZE*n) would still work because
    it's much nicer API.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-05-09 12:28    [W:0.025 / U:41.816 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site