On Fri, Aug 30, 2024 at 11:07:32AM GMT, Vlastimil Babka wrote:

On 8/29/24 19:53, Shakeel Butt wrote:

quoted

At the moment, the slab objects are charged to the memcg at the
allocation time. However there are cases where slab objects are
allocated at the time where the right target memcg to charge it to is
not known. One such case is the network sockets for the incoming
connection which are allocated in the softirq context.

Couple hundred thousand connections are very normal on large loaded
server and almost all of those sockets underlying those connections get
allocated in the softirq context and thus not charged to any memcg.
However later at the accept() time we know the right target memcg to
charge. Let's add new API to charge already allocated objects, so we can
have better accounting of the memory usage.

To measure the performance impact of this change, tcp_crr is used from
the neper [1] performance suite. Basically it is a network ping pong
test with new connection for each ping pong.

The server and the client are run inside 3 level of cgroup hierarchy
using the following commands:

Server:
 $ tcp_crr -6

Client:
 $ tcp_crr -6 -c -H ${server_ip}

If the client and server run on different machines with 50 GBPS NIC,
there is no visible impact of the change.

For the same machine experiment with v6.11-rc5 as base.

          base (throughput)     with-patch
tcp_crr   14545 (+- 80)         14463 (+- 56)

It seems like the performance impact is within the noise.

Link: https://github.com/google/neper [1]
Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>

Thanks, pushed to slab/for-next for test coverage, hopefully net people will
ack.

Also one thing:

We should add some kernel doc for this, no? Explaining when people are
supposed to use this, that objects from KMALLOC_NORMAL will be ignored, and
what the return value means (including where it's faked to be true).

Yes this makes sense. I will add this info similar to the kmalloc()
have. Should I send a v4 with this details?