RE: [PATCH net-next 1/2] net: Keep sk->sk_forward_alloc as a proper size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Remove the invalid mail addr added unintentionally.

> -----Original Message-----
> From: Zhang, Cathy
> Sent: Friday, May 12, 2023 10:39 AM
> To: Shakeel Butt <shakeelb@xxxxxxxxxx>; Zhang@xxxxxxxxxx
> Cc: Eric Dumazet <edumazet@xxxxxxxxxx>; Linux MM <linux-
> mm@xxxxxxxxx>; Cgroups <cgroups@xxxxxxxxxxxxxxx>; Paolo Abeni
> <pabeni@xxxxxxxxxx>; davem@xxxxxxxxxxxxx; kuba@xxxxxxxxxx;
> Brandeburg@xxxxxxxxxx; Brandeburg, Jesse <jesse.brandeburg@xxxxxxxxx>;
> Srinivas@xxxxxxxxxx; Srinivas, Suresh <suresh.srinivas@xxxxxxxxx>;
> Chen@xxxxxxxxxx; Chen, Tim C <tim.c.chen@xxxxxxxxx>; You@xxxxxxxxxx;
> You, Lizhen <Lizhen.You@xxxxxxxxx>; eric.dumazet@xxxxxxxxx;
> netdev@xxxxxxxxxxxxxxx
> Subject: RE: [PATCH net-next 1/2] net: Keep sk->sk_forward_alloc as a proper
> size
> 
> 
> 
> > -----Original Message-----
> > From: Shakeel Butt <shakeelb@xxxxxxxxxx>
> > Sent: Friday, May 12, 2023 5:19 AM
> > To: Zhang@xxxxxxxxxx; Zhang, Cathy <cathy.zhang@xxxxxxxxx>
> > Cc: Eric Dumazet <edumazet@xxxxxxxxxx>; Linux MM <linux-
> > mm@xxxxxxxxx>; Cgroups <cgroups@xxxxxxxxxxxxxxx>; Paolo Abeni
> > <pabeni@xxxxxxxxxx>; davem@xxxxxxxxxxxxx; kuba@xxxxxxxxxx;
> > Brandeburg@xxxxxxxxxx; Brandeburg, Jesse
> <jesse.brandeburg@xxxxxxxxx>;
> > Srinivas@xxxxxxxxxx; Srinivas, Suresh <suresh.srinivas@xxxxxxxxx>;
> > Chen@xxxxxxxxxx; Chen, Tim C <tim.c.chen@xxxxxxxxx>;
> You@xxxxxxxxxx;
> > You, Lizhen <lizhen.you@xxxxxxxxx>; eric.dumazet@xxxxxxxxx;
> > netdev@xxxxxxxxxxxxxxx
> > Subject: Re: [PATCH net-next 1/2] net: Keep sk->sk_forward_alloc as a
> > proper size
> >
> > On Thu, May 11, 2023 at 09:26:46AM +0000, Zhang, Cathy wrote:
> > >
> > [...]
> > >
> > >      8.98%  mc-worker        [kernel.vmlinux]          [k] page_counter_cancel
> > >             |
> > >              --8.97%--page_counter_cancel
> > >                        |
> > >                         --8.97%--page_counter_uncharge
> > >                                   drain_stock
> > >                                   __refill_stock
> > >                                   refill_stock
> > >                                   |
> > >                                    --8.91%--try_charge_memcg
> > >                                              mem_cgroup_charge_skmem
> >
> > I do want to understand for above which specific condition in
> > __refill_stock is causing to drain stock in the charge code path. Can
> > you please re-run and profile your test with following code snippet
> > (or use any other mechanism which can answer the question)?
> >
> > From f1d91043f21f4b29717c78615b374d79fc021d1f Mon Sep 17 00:00:00
> > 2001
> > From: Shakeel Butt <shakeelb@xxxxxxxxxx>
> > Date: Thu, 11 May 2023 20:00:19 +0000
> > Subject: [PATCH] Debug drain on charging.
> >
> > ---
> >  mm/memcontrol.c | 14 ++++++++++++--
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c index
> > d31fb1e2cb33..4c1c3d90a4a3 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -2311,6 +2311,16 @@ static void drain_local_stock(struct
> > work_struct
> > *dummy)
> >  		obj_cgroup_put(old);
> >  }
> >
> > +static noinline void drain_stock_1(struct memcg_stock_pcp *stock) {
> > +	drain_stock(stock);
> > +}
> > +
> > +static noinline void drain_stock_2(struct memcg_stock_pcp *stock) {
> > +	drain_stock(stock);
> > +}
> > +
> >  /*
> >   * Cache charges(val) to local per_cpu area.
> >   * This will be consumed by consume_stock() function, later.
> > @@ -2321,14 +2331,14 @@ static void __refill_stock(struct mem_cgroup
> > *memcg, unsigned int nr_pages)
> >
> >  	stock = this_cpu_ptr(&memcg_stock);
> >  	if (READ_ONCE(stock->cached) != memcg) { /* reset if necessary */
> > -		drain_stock(stock);
> > +		drain_stock_1(stock);
> >  		css_get(&memcg->css);
> >  		WRITE_ONCE(stock->cached, memcg);
> >  	}
> >  	stock->nr_pages += nr_pages;
> >
> >  	if (stock->nr_pages > MEMCG_CHARGE_BATCH)
> > -		drain_stock(stock);
> > +		drain_stock_2(stock);
> >  }
> >
> >  static void refill_stock(struct mem_cgroup *memcg, unsigned int
> > nr_pages)
> > --
> > 2.40.1.606.ga4b1b128d6-goog
> 
> Hi Shakeel,
> 
> Run with the temp change you provided,  the output shows it comes to
> drain_stock_1(), Here is the call trace:
> 
>      8.96%  mc-worker        [kernel.vmlinux]            [k] page_counter_cancel
>             |
>              --8.95%--page_counter_cancel
>                        |
>                         --8.95%--page_counter_uncharge
>                                   drain_stock_1
>                                   __refill_stock
>                                   refill_stock
>                                   |
>                                    --8.88%--try_charge_memcg
>                                              mem_cgroup_charge_skmem
>                                              |
>                                               --8.87%--__sk_mem_raise_allocated
>                                                         __sk_mem_schedule
>                                                         |
>                                                         |--5.37%--tcp_try_rmem_schedule
>                                                         |          tcp_data_queue
>                                                         |          tcp_rcv_established
>                                                         |          tcp_v4_do_rcv






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux