On Fri, Mar 16, 2007 at 07:25:53AM +1100, Nick Piggin wrote:
> I would just avoid the complexity and setup/teardown costs, and just
> use a vmalloc'ed global hash for NUMA.
This patch is not the way to go, but neither are vmalloc()'d global
hashtables. When you just happen to hash to the wrong
Ulrich Drepper wrote:
On 3/15/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
There should be little contention on the memory in the global hash
anyway,
because we can roughly reduce contention as a factor of
hash-size/cacheline-size.
What we will have are cache misses on the global table... but
On 3/15/07, Nick Piggin <[EMAIL PROTECTED]> wrote:
There should be little contention on the memory in the global hash anyway,
because we can roughly reduce contention as a factor of
hash-size/cacheline-size.
What we will have are cache misses on the global table... but we're going to
get cache
Eric Dumazet wrote:
[PATCH 2/3] FUTEX : introduce private hashtables
This patch introduces a separate hashtable per process to store _PRIVATE
futexes.
This hashtable is dynamically allocated on the first _PRIVATE futex syscall.
If memory cannot be allocated, the process will use the global
[PATCH 2/3] FUTEX : introduce private hashtables
This patch introduces a separate hashtable per process to store _PRIVATE
futexes.
This hashtable is dynamically allocated on the first _PRIVATE futex syscall.
If memory cannot be allocated, the process will use the global hashtable.
Using
[PATCH 2/3] FUTEX : introduce private hashtables
This patch introduces a separate hashtable per process to store _PRIVATE
futexes.
This hashtable is dynamically allocated on the first _PRIVATE futex syscall.
If memory cannot be allocated, the process will use the global hashtable.
Using
Eric Dumazet wrote:
[PATCH 2/3] FUTEX : introduce private hashtables
This patch introduces a separate hashtable per process to store _PRIVATE
futexes.
This hashtable is dynamically allocated on the first _PRIVATE futex syscall.
If memory cannot be allocated, the process will use the global
On 3/15/07, Nick Piggin [EMAIL PROTECTED] wrote:
There should be little contention on the memory in the global hash anyway,
because we can roughly reduce contention as a factor of
hash-size/cacheline-size.
What we will have are cache misses on the global table... but we're going to
get cache
Ulrich Drepper wrote:
On 3/15/07, Nick Piggin [EMAIL PROTECTED] wrote:
There should be little contention on the memory in the global hash
anyway,
because we can roughly reduce contention as a factor of
hash-size/cacheline-size.
What we will have are cache misses on the global table... but
On Fri, Mar 16, 2007 at 07:25:53AM +1100, Nick Piggin wrote:
I would just avoid the complexity and setup/teardown costs, and just
use a vmalloc'ed global hash for NUMA.
This patch is not the way to go, but neither are vmalloc()'d global
hashtables. When you just happen to hash to the wrong
10 matches
Mail list logo
