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

[Manfred Spraul <manfred@colorfullife.com>]

Pekka Enberg wrote:

> Hi Steven,
>
> On 12/26/05, Steven Rostedt <rostedt@goodmis.org> wrote:
>  
>
> > Now, maybe NUMA and vmalloc might be a good reason to start a new
> > allocation system along side of slab?
> >    
>
> A better approach would probably be to introduce a vmem layer similar
> to what Solaris has to solve I/O memory and vmalloc issue. What NUMA
> issue are you referring to btw? I don't see any problem with the
> current design (in fact, I stole it for my magazine allocator too).
> It's just that the current implementation is bit hard to understand.
>
>  
This is virt_to_page() on i386: the object address is in %esi
    lea    0x40000000(%esi),%eax
    mov    0x0,%edx [0x0 is actually mem_map]
    shr    $0xc,%eax
    shl    $0x5,%eax
Just read the mem_map pointer and a few calculations.
And now retrieve the cachep pointer:
   mov    0x18(%eax,%edx,1),%edx

With NUMA on i386 (GENERIC_ARCH)
   lea    0x40000000(%edi),%eax
   mov    %eax,%ebx
   shr    $0x1c,%eax
   movsbl 0x0(%eax),%eax [ 0x0 is physnode_map]
   shr    $0xc,%ebx
   mov    0x0(,%eax,4),%ecx [0x0 is node_data]
   mov    %ebx,%eax
   mov    0xaa0(%ecx),%edx
   sub    %edx,%eax
   mov    0xa98(%ecx),%edx
   shl    $0x5,%eax
4 memory accesses.
   mov    0x18(%eax,%edx,1),%ebp

--
   Manfred
-
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/