From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CEC7BC43381 for ; Sun, 31 Mar 2019 19:23:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A209120870 for ; Sun, 31 Mar 2019 19:23:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731421AbfCaTXg (ORCPT ); Sun, 31 Mar 2019 15:23:36 -0400 Received: from mail-lf1-f68.google.com ([209.85.167.68]:41281 "EHLO mail-lf1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731283AbfCaTXg (ORCPT ); Sun, 31 Mar 2019 15:23:36 -0400 Received: by mail-lf1-f68.google.com with SMTP id 10so4704367lfr.8 for ; Sun, 31 Mar 2019 12:23:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M/9RRp59wIXWbS95+YpupoWi6TPudhqNj3RoHOhcIyk=; b=apTEqohMlJTqX9j07MzmPKZFqrLv5wgMHS3TRleqwTZAvBfPAyXevSYFTMfKgADFpL zVtY+Ygp7MOfxtb6/fWZ0ghJeW7vAnQHl6yOeE4fgwW9a4cqICsEumin0lhrhdlOjxc1 c6kBmVTFZMvD+7PUcsE1z3weGYXseM0uZ5iAfFq7cRaB6SGN8WmEES5FJMvb3HoCXqMK yOsc7iqHrQoBKPCsA15hl0giqp70fqYADmm4MSJGDXD4mgCg5tjV++mA/aeeyuxLGhOT HX2cAg8RoYCMNtlqxFF7Zswkac1/BYFo0d4N9fEGmIM58cds2rr/bAoQpX4AexO73wa/ Dy9Q== X-Gm-Message-State: APjAAAWWN9RpX+49Prsg9E8B58KTSiAjOl68H1kWcJhyugVyCgm1B+ru QktJPr1Xl9jL0/aK+R42nVTIsaUtCVbzCYnYGfhQXA== X-Google-Smtp-Source: APXvYqwMpSs2Kyz34jezSoGax8i7KSBxujP44Tuuxn0U7wrbbZ3cbcW1Htp9axnmYBxBGbcOuXf2VP2z3zhp/aQPCrY= X-Received: by 2002:ac2:43b7:: with SMTP id t23mr10756460lfl.85.1554060214082; Sun, 31 Mar 2019 12:23:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Matteo Croce Date: Sun, 31 Mar 2019 21:22:58 +0200 Message-ID: Subject: Re: [PATCH net-next 0/2] sctp: fully support memory accounting To: Xin Long Cc: network dev , linux-sctp@vger.kernel.org, Marcelo Ricardo Leitner , Neil Horman , "David S . Miller" , Vladis Dronov Content-Type: text/plain; charset="UTF-8" Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Mar 31, 2019 at 10:53 AM Xin Long wrote: > > sctp memory accounting is added in this patchset by using > these kernel APIs on send side: > > - sk_mem_charge() > - sk_mem_uncharge() > - sk_wmem_schedule() > - sk_under_memory_pressure() > - sk_mem_reclaim() > > and these on receive side: > > - sk_mem_charge() > - sk_mem_uncharge() > - sk_rmem_schedule() > - sk_under_memory_pressure() > - sk_mem_reclaim() > > With sctp memory accounting, we can limit the memory allocation by > either sysctl: > > # sysctl -w net.sctp.sctp_mem="10 20 50" > > or cgroup: > > # echo $((8<<14)) > \ > /sys/fs/cgroup/memory/sctp_mem/memory.kmem.tcp.limit_in_bytes > > When the socket is under memory pressure, the send side will block > and wait, while the receive side will renege or drop. > I have tested this series with a tool which creates lot of SCTP sockets and writes into them, without never reading. Before the patch I was able to escape the cgroup limit and fill the system memory, and the OOM killer killed random processes: [ 317.348911] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),global_oom,task_memcg=/system.slice/ifup@eth0.service,task=dhclient,pid=188,uid=0 [ 317.349084] Out of memory: Killed process 188 (dhclient) total-vm:9484kB, anon-rss:1280kB, file-rss:1424kB, shmem-rss:0kB [ 317.743943] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),global_oom,task_memcg=/system.slice/systemd-journald.service,task=systemd-journal,pid=85,uid=0 [ 317.744093] Out of memory: Killed process 85 (systemd-journal) total-vm:24592kB, anon-rss:1024kB, file-rss:1112kB, shmem-rss:652kB [ 317.921049] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),global_oom,task_memcg=/system.slice/cron.service,task=cron,pid=222,uid=0 [ 317.921209] Out of memory: Killed process 222 (cron) total-vm:8692kB, anon-rss:276kB, file-rss:1540kB, shmem-rss:0kB Now the OOM killer behaves correctly and always kills the processes in the right cgroup: [ 512.100054] Tasks state (memory values in pages): [ 512.100122] [ pid ] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name [ 512.100256] [ 838] 0 838 550 184 36864 0 0 sctprank [ 512.100452] [ 841] 0 841 550 18 36864 0 0 sctprank [ 512.100573] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),oom_memcg=/sctp,task_memcg=/sctp,task=sctprank,pid=838,uid=0 [ 512.100700] Memory cgroup out of memory: Killed process 838 (sctprank) total-vm:2200kB, anon-rss:64kB, file-rss:672kB, shmem-rss:0kB [ 512.100899] oom_reaper: reaped process 838 (sctprank), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB Series ACK. Tested-by: Matteo Croce -- Matteo Croce per aspera ad upstream