Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp->nodeid;)

2007-04-02 Thread Siddha, Suresh B
On Mon, Apr 02, 2007 at 05:23:20PM -0700, Christoph Lameter wrote: > On Mon, 2 Apr 2007, Siddha, Suresh B wrote: > > > Set the node_possible_map at runtime. On a non NUMA system, > > num_possible_nodes() will now say '1' > > How does this relate to nr_node_ids? With this patch, nr_node_ids on

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp->nodeid;)

2007-04-02 Thread Christoph Lameter
On Mon, 2 Apr 2007, Siddha, Suresh B wrote: > Set the node_possible_map at runtime. On a non NUMA system, > num_possible_nodes() will now say '1' How does this relate to nr_node_ids? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp->nodeid;)

2007-04-02 Thread Siddha, Suresh B
On Fri, Mar 23, 2007 at 03:12:10PM +0100, Andi Kleen wrote: > > But that is based on compile time option, isn't it? Perhaps I need > > to use some other mechanism to find out the platform is not NUMA capable.. > > We can probably make it runtime on x86. That will be needed sooner or > later for

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp-nodeid;)

2007-04-02 Thread Siddha, Suresh B
On Fri, Mar 23, 2007 at 03:12:10PM +0100, Andi Kleen wrote: But that is based on compile time option, isn't it? Perhaps I need to use some other mechanism to find out the platform is not NUMA capable.. We can probably make it runtime on x86. That will be needed sooner or later for correct

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp-nodeid;)

2007-04-02 Thread Christoph Lameter
On Mon, 2 Apr 2007, Siddha, Suresh B wrote: Set the node_possible_map at runtime. On a non NUMA system, num_possible_nodes() will now say '1' How does this relate to nr_node_ids? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp-nodeid;)

2007-04-02 Thread Siddha, Suresh B
On Mon, Apr 02, 2007 at 05:23:20PM -0700, Christoph Lameter wrote: On Mon, 2 Apr 2007, Siddha, Suresh B wrote: Set the node_possible_map at runtime. On a non NUMA system, num_possible_nodes() will now say '1' How does this relate to nr_node_ids? With this patch, nr_node_ids on non NUMA

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp->nodeid;)

2007-03-23 Thread Andi Kleen
On Thu, Mar 22, 2007 at 06:25:16PM -0700, Christoph Lameter wrote: > On Thu, 22 Mar 2007, Siddha, Suresh B wrote: > > > > You should check num_possible_nodes(), or nr_node_ids (this one is > > > cheaper, > > > its a variable instead of a function call) > > > > But that is based on compile time

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp->nodeid;)

2007-03-23 Thread Andi Kleen
> But that is based on compile time option, isn't it? Perhaps I need > to use some other mechanism to find out the platform is not NUMA capable.. We can probably make it runtime on x86. That will be needed sooner or later for correct NUMA hotplug support anyways. -Andi - To unsubscribe from

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp-nodeid;)

2007-03-23 Thread Andi Kleen
But that is based on compile time option, isn't it? Perhaps I need to use some other mechanism to find out the platform is not NUMA capable.. We can probably make it runtime on x86. That will be needed sooner or later for correct NUMA hotplug support anyways. -Andi - To unsubscribe from this

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp-nodeid;)

2007-03-23 Thread Andi Kleen
On Thu, Mar 22, 2007 at 06:25:16PM -0700, Christoph Lameter wrote: On Thu, 22 Mar 2007, Siddha, Suresh B wrote: You should check num_possible_nodes(), or nr_node_ids (this one is cheaper, its a variable instead of a function call) But that is based on compile time option, isn't

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp->nodeid;)

2007-03-22 Thread Christoph Lameter
On Thu, 22 Mar 2007, Siddha, Suresh B wrote: > > You should check num_possible_nodes(), or nr_node_ids (this one is cheaper, > > its a variable instead of a function call) > > But that is based on compile time option, isn't it? Perhaps I need > to use some other mechanism to find out the

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp->nodeid;)

2007-03-22 Thread Eric Dumazet
Siddha, Suresh B a écrit : On Thu, Mar 22, 2007 at 11:12:39PM +0100, Eric Dumazet wrote: Siddha, Suresh B a écrit : + if (num_online_nodes() == 1) + use_alien_caches = 0; + Unfortunatly this part is wrong. oops. You should check num_possible_nodes(), or nr_node_ids

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp->nodeid;)

2007-03-22 Thread Siddha, Suresh B
On Thu, Mar 22, 2007 at 11:12:39PM +0100, Eric Dumazet wrote: > Siddha, Suresh B a écrit : > >+if (num_online_nodes() == 1) > >+use_alien_caches = 0; > >+ > > Unfortunatly this part is wrong. oops. > > You should check num_possible_nodes(), or nr_node_ids (this one is cheaper,

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp->nodeid;)

2007-03-22 Thread Eric Dumazet
Siddha, Suresh B a écrit : Christoph, While we are at this topic, recently I had reports that cache_free_alien() is costly on non NUMA platforms too (similar to the cache miss issues that Eric was referring to on NUMA) and the appended patch seems to fix it for non NUMA atleast. Appended patch

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp->nodeid;)

2007-03-22 Thread Christoph Lameter
On Thu, 22 Mar 2007, Siddha, Suresh B wrote: > @@ -1394,6 +1394,9 @@ void __init kmem_cache_init(void) > int order; > int node; > > + if (num_online_nodes() == 1) > + use_alien_caches = 0; > + What happens if you bring up a second node? - To unsubscribe from this

non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp->nodeid;)

2007-03-22 Thread Siddha, Suresh B
Christoph, While we are at this topic, recently I had reports that cache_free_alien() is costly on non NUMA platforms too (similar to the cache miss issues that Eric was referring to on NUMA) and the appended patch seems to fix it for non NUMA atleast. Appended patch gives a nice 1% perf

non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp-nodeid;)

2007-03-22 Thread Siddha, Suresh B
Christoph, While we are at this topic, recently I had reports that cache_free_alien() is costly on non NUMA platforms too (similar to the cache miss issues that Eric was referring to on NUMA) and the appended patch seems to fix it for non NUMA atleast. Appended patch gives a nice 1% perf

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp-nodeid;)

2007-03-22 Thread Christoph Lameter
On Thu, 22 Mar 2007, Siddha, Suresh B wrote: @@ -1394,6 +1394,9 @@ void __init kmem_cache_init(void) int order; int node; + if (num_online_nodes() == 1) + use_alien_caches = 0; + What happens if you bring up a second node? - To unsubscribe from this list:

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp-nodeid;)

2007-03-22 Thread Eric Dumazet
Siddha, Suresh B a écrit : Christoph, While we are at this topic, recently I had reports that cache_free_alien() is costly on non NUMA platforms too (similar to the cache miss issues that Eric was referring to on NUMA) and the appended patch seems to fix it for non NUMA atleast. Appended patch

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp-nodeid;)

2007-03-22 Thread Siddha, Suresh B
On Thu, Mar 22, 2007 at 11:12:39PM +0100, Eric Dumazet wrote: Siddha, Suresh B a écrit : +if (num_online_nodes() == 1) +use_alien_caches = 0; + Unfortunatly this part is wrong. oops. You should check num_possible_nodes(), or nr_node_ids (this one is cheaper, its a

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp-nodeid;)

2007-03-22 Thread Eric Dumazet
Siddha, Suresh B a écrit : On Thu, Mar 22, 2007 at 11:12:39PM +0100, Eric Dumazet wrote: Siddha, Suresh B a écrit : + if (num_online_nodes() == 1) + use_alien_caches = 0; + Unfortunatly this part is wrong. oops. You should check num_possible_nodes(), or nr_node_ids

Re: non-NUMA cache_free_alien() (was Re: [RFC] SLAB : NUMA cache_free_alien() very expensive because of virt_to_slab(objp); nodeid = slabp-nodeid;)

2007-03-22 Thread Christoph Lameter
On Thu, 22 Mar 2007, Siddha, Suresh B wrote: You should check num_possible_nodes(), or nr_node_ids (this one is cheaper, its a variable instead of a function call) But that is based on compile time option, isn't it? Perhaps I need to use some other mechanism to find out the platform is