netdev - Re: [PATCH net-next 1/2] net: Keep sk->sk_forward

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230512050429.22du3gt6rrq6e37a@google.com>
Date: Fri, 12 May 2023 05:06:55 +0000
From: Shakeel Butt <shakeelb@...gle.com>
To: cathy.zhang@...el.com
Cc: Eric Dumazet <edumazet@...gle.com>, Linux MM <linux-mm@...ck.org>, 
	Cgroups <cgroups@...r.kernel.org>, Paolo Abeni <pabeni@...hat.com>, davem@...emloft.net, 
	kuba@...nel.org, Brandeburg@...gle.com, 
	Brandeburg Jesse <jesse.brandeburg@...el.com>, Srinivas Suresh <suresh.srinivas@...el.com>, 
	Chen Tim C <tim.c.chen@...el.com>, You Lizhen <lizhen.you@...el.com>, eric.dumazet@...il.com, 
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next 1/2] net: Keep sk->sk_forward_alloc as a proper size

On Fri, May 12, 2023 at 03:23:45AM +0000, Zhang, Cathy wrote:
> Remove the invalid mail addr added unintentionally.
> 

Sorry that was my buggy script.

[...]
> > 
> > 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
> 

Thanks a lot. This tells us that one or both of following scenarios are
happening:

1. In the softirq recv path, the kernel is processing packets from
multiple memcgs.

2. The process running on the CPU belongs to memcg which is different
from the memcgs whose packets are being received on that CPU.

BTW have you seen this performance issue when you run the client and
server on different machines? I am wondering if RFS would be good enough
for such scenario and we only need to worry about the same machine case.