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
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 opp
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 n
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
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
___
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
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?
>
> Lo
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 = thi
On Thu, 1 Nov 2012, Jesse Gross wrote:
> On Thu, Nov 1, 2012 at 7:33 AM, Christoph Lameter wrote:
> > 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?
&g
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
On Wed, 31 Oct 2012, Shan Wei wrote:
> --- a/net/openvswitch/datapath.c
> +++ 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_
10 matches
Mail list logo
