The patch titled
Subject: af_unix: charge buffers to kmemcg
has been added to the -mm tree. Its filename is
af_unix-charge-buffers-to-kmemcg.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/af_unix-charge-buffers-to-kmemcg.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/af_unix-charge-buffers-to-kmemcg.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Vladimir Davydov <vdavydov@xxxxxxxxxxxxx>
Subject: af_unix: charge buffers to kmemcg
Unix sockets can consume a significant amount of system memory, hence
they should be accounted to kmemcg.
Since unix socket buffers are always allocated from process context,
all we need to do to charge them to kmemcg is set __GFP_ACCOUNT in
sock->sk_allocation mask.
Eric asked:
> 1) What happens when a buffer, allocated from socket <A> lands in a
> different socket <B>, maybe owned by another user/process.
>
> Who owns it now, in term of kmemcg accounting ?
We never move memcg charges. E.g. if two processes from different
cgroups are sharing a memory region, each page will be charged to the
process which touched it first. Or if two processes are working with the
same directory tree, inodes and dentries will be charged to the first
user. The same is fair for unix socket buffers - they will be charged to
the sender.
> 2) Has performance impact been evaluated ?
I ran netperf STREAM_STREAM with default options in a kmemcg on
a 4 core x 2 HT box. The results are below:
# clients bandwidth (10^6bits/sec)
base patched
1 67643 +- 725 64874 +- 353 - 4.0 %
4 193585 +- 2516 186715 +- 1460 - 3.5 %
8 194820 +- 377 187443 +- 1229 - 3.7 %
So the accounting doesn't come for free - it takes ~4% of performance. I
believe we could optimize it by using per cpu batching not only on charge,
but also on uncharge in memcg core, but that's beyond the scope of this
patch set - I'll take a look at this later.
Anyway, if performance impact is found to be unacceptable, it is always
possible to disable kmem accounting at boot time (cgroup.memory=nokmem) or
not use memory cgroups at runtime at all (thanks to jump labels there'll
be no overhead even if they are compiled in).
Link: http://lkml.kernel.org/r/fcfe6cae27a59fbc5e40145664b3cf085a560c68.1464079538.git.vdavydov@xxxxxxxxxxxxx
Signed-off-by: Vladimir Davydov <vdavydov@xxxxxxxxxxxxx>
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>
Cc: Johannes Weiner <hannes@xxxxxxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxxxx>
Cc: Eric Dumazet <eric.dumazet@xxxxxxxxx>
Cc: Minchan Kim <minchan@xxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
net/unix/af_unix.c | 1 +
1 file changed, 1 insertion(+)
diff -puN net/unix/af_unix.c~af_unix-charge-buffers-to-kmemcg net/unix/af_unix.c
--- a/net/unix/af_unix.c~af_unix-charge-buffers-to-kmemcg
+++ a/net/unix/af_unix.c
@@ -769,6 +769,7 @@ static struct sock *unix_create1(struct
lockdep_set_class(&sk->sk_receive_queue.lock,
&af_unix_sk_receive_queue_lock_key);
+ sk->sk_allocation = GFP_KERNEL_ACCOUNT;
sk->sk_write_space = unix_write_space;
sk->sk_max_ack_backlog = net->unx.sysctl_max_dgram_qlen;
sk->sk_destruct = unix_sock_destructor;
_
Patches currently in -mm which might be from vdavydov@xxxxxxxxxxxxx are
mm-zap-zone_oom_locked.patch
mm-oom-add-memcg-to-oom_control.patch
mm-remove-pointless-struct-in-struct-page-definition.patch
mm-clean-up-non-standard-page-_mapcount-users.patch
mm-memcontrol-cleanup-kmem-charge-functions.patch
mm-charge-uncharge-kmemcg-from-generic-page-allocator-paths.patch
mm-memcontrol-teach-uncharge_list-to-deal-with-kmem-pages.patch
arch-x86-charge-page-tables-to-kmemcg.patch
pipe-account-to-kmemcg.patch
af_unix-charge-buffers-to-kmemcg.patch
--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
