lkml.org 
[lkml]   [2005]   [Dec]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] SLAB - have index_of bug at compile time.
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/

\
 
 \ /
  Last update: 2005-12-27 00:25    [W:0.032 / U:1.940 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site