Re: [ovs-dev] [patch v2 1/3] mm: remove GFP_THISNODE

2015-03-02 Thread Christoph Lameter
On Mon, 2 Mar 2015, Vlastimil Babka wrote: So it would be IMHO better for longer-term maintainability to have the relevant __GFP_THISNODE callers pass also __GFP_NO_KSWAPD to denote these opportunistic allocation attempts, instead of having this subtle semantic You are thinking about an

Re: [ovs-dev] [patch v2 1/3] mm: remove GFP_THISNODE

2015-03-02 Thread Christoph Lameter
On Mon, 2 Mar 2015, Vlastimil Babka wrote: You are thinking about an opportunistic allocation attempt in SLAB? AFAICT SLAB allocations should trigger reclaim. Well, let me quote your commit 952f3b51beb5: This was about global reclaim. Local reclaim is good and that can be done via

Re: [ovs-dev] [patch v2 1/3] mm: remove GFP_THISNODE

2015-02-27 Thread Christoph Lameter
On Fri, 27 Feb 2015, David Rientjes wrote: +/* + * Construct gfp mask to allocate from a specific node but do not invoke reclaim + * or warn about failures. + */ We should be triggering reclaim from slab allocations. Why would we not do this? Otherwise we will be going uselessly off node

Re: [ovs-dev] [patch 1/2] mm: remove GFP_THISNODE

2015-02-25 Thread Christoph Lameter
On Wed, 25 Feb 2015, David Rientjes wrote: NOTE: this is not about __GFP_THISNODE, this is only about GFP_THISNODE. Well but then its not removing it. You are replacing it with an inline function. + +/* + * Construct gfp mask to allocate from a specific node but do not invoke reclaim + *

Re: [ovs-dev] [PATCH v3 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper

2012-11-09 Thread Christoph Lameter
On Fri, 9 Nov 2012, Shan Wei wrote: just use more faster this_cpu_ptr instead of per_cpu_ptr(p, smp_processor_id()); Reviewed-by: Christoph Lameter c...@linux.com ___ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev

Re: [ovs-dev] [PATCH 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper

2012-11-08 Thread Christoph Lameter
On Thu, 8 Nov 2012, Shan Wei wrote: Christoph Lameter said, at 2012/11/3 1:46: u64_stats_update_begin(stats-sync); stats-tx_packets++; Use this_cpu_inc(vport-percpu_stats-packets) here? Lots of network drivers use u64_stats_sync infrastructure for statistics So

Re: [ovs-dev] [PATCH 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper

2012-11-02 Thread Christoph Lameter
On Sat, 3 Nov 2012, Shan Wei wrote: +++ b/net/openvswitch/datapath.c @@ -208,7 +208,7 @@ void ovs_dp_process_received_packet(struct vport *p, struct sk_buff *skb) int error; int key_len; - stats = per_cpu_ptr(dp-stats_percpu, smp_processor_id()); + stats =

Re: [ovs-dev] [PATCH 4/9] net: openvswitch: use this_cpu_ptr per-cpu helper

2012-11-01 Thread Christoph Lameter
On Thu, 1 Nov 2012, Shan Wei wrote: But for different field in same per-cpu variable, how to guarantee n_missed and n_hit are from same cpu? this_cpu_read(dp-stats_percpu-n_missed); [processor changed] this_cpu_read(dp-stats_percpu-n_hit); What does current guarantee that? If it is