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=-2.3 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 380FCC43381 for ; Tue, 2 Apr 2019 03:36:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id E7150207E0 for ; Tue, 2 Apr 2019 03:36:16 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="pXVFgJMC" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728858AbfDBDgQ (ORCPT ); Mon, 1 Apr 2019 23:36:16 -0400 Received: from mail-qk1-f193.google.com ([209.85.222.193]:44944 "EHLO mail-qk1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726501AbfDBDgP (ORCPT ); Mon, 1 Apr 2019 23:36:15 -0400 Received: by mail-qk1-f193.google.com with SMTP id y5so7042571qkc.11; Mon, 01 Apr 2019 20:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=O05OaeRayBZIVByL4hQMmXMZ1r9oPke1CJhuUyR9gTE=; b=pXVFgJMC9f24rZVa8YZCL/hJANru06P1/PcQKIVeNkJFLWXdWZFiUFYJENr7JJGTVQ qb/zmBpEuHM+TttSC/waQluQRmikqcTwi7lfb8TO4dTwuhr8anfo4uKjNA+sUvOfgrCX jggaB5RpqYDOXQDnxM4jxzsgJLWb/2p+dKx6PwwoE9qzLVpcJKXJ9kCTdOU/W5rT9m1T 9BFl9xZsH2domIcxKvqTcr7Em77wmWv+LdXJe9YhLyBESBTdceXXQ7p/lTDstgBmjOv4 HGo95O9Dbdvgf1LzeLWpjWMGMKKWtG5fi/fEjPsDgCN/hj9Afyq7ZQ+0K5aIpOxEhhLZ 7wqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=O05OaeRayBZIVByL4hQMmXMZ1r9oPke1CJhuUyR9gTE=; b=FTwL2GzSMcecG1GYZ283c+C/JV1cYTWoeZ+wwjywvhimSNa7lnMeAnWjoIGEwsm5sY Y9NeIIEcqVAHIDRwiUgOF67/5NpkQDPd60w87h8YAbUzKawOECoOJLmuk8/l/3rbWSgh FxAzyDMvKfO70SWFy/1nND1AbNkA8gNKZymmD9p5kSrCQ6PI2LNvVaJEE2G3gbhKnNAq dq9VKP/iU199s7KTMS9o9oaB9i3JI8f0cvtFBUVYaxsl8VRyCisEqZkinQKBlzpHsTs1 z1x+TVZOMMWr0n4K0A/mGFsHwvdcDIKcPJODPbFiTZzanlx1ZqRQNEcLSMUZJZXjZH4J pgxQ== X-Gm-Message-State: APjAAAUmpBtul2cmlsI/hF0D0rQ15R/yBdlnVlX/X8SmYbpatjo8kC0o 9c2sg6GSsYrKdubrCIA0Q3c1MrvoM4AEFg== X-Google-Smtp-Source: APXvYqxKP7rgE6y8oRe8WvPdN0jkRWVZQ19v9tATxfMJs2eEHyZ3p1tUR0t4QDNh0zVqc9eDDbYj0g== X-Received: by 2002:ae9:e007:: with SMTP id m7mr53292852qkk.248.1554176174519; Mon, 01 Apr 2019 20:36:14 -0700 (PDT) Received: from localhost.localdomain ([2001:1284:f016:2044:bfe6:d5b1:318e:446e]) by smtp.gmail.com with ESMTPSA id i24sm7912473qti.76.2019.04.01.20.36.12 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 01 Apr 2019 20:36:13 -0700 (PDT) Received: by localhost.localdomain (Postfix, from userid 1000) id 80A7C180C43; Tue, 2 Apr 2019 00:36:10 -0300 (-03) Date: Tue, 2 Apr 2019 00:36:10 -0300 From: Marcelo Ricardo Leitner To: Neil Horman Cc: Xin Long , network dev , linux-sctp@vger.kernel.org, davem@davemloft.net, Matteo Croce , Vladis Dronov Subject: Re: [PATCH net-next 0/2] sctp: fully support memory accounting Message-ID: <20190402033610.GO16876@localhost.localdomain> References: <20190401113110.GA20717@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190401113110.GA20717@hmswarspite.think-freely.org> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Mon, Apr 01, 2019 at 07:31:10AM -0400, Neil Horman wrote: > On Sun, Mar 31, 2019 at 04:53:45PM +0800, 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. > > > > Xin Long (2): > > sctp: implement memory accounting on tx path > > sctp: implement memory accounting on rx path > > > > include/net/sctp/sctp.h | 2 +- > > net/sctp/sm_statefuns.c | 6 ++++-- > > net/sctp/socket.c | 10 ++++++++-- > > net/sctp/ulpevent.c | 19 ++++++++----------- > > net/sctp/ulpqueue.c | 3 ++- > > 5 files changed, 23 insertions(+), 17 deletions(-) > > > > -- > > 2.1.0 > > > > > I don't have a problem with either of these patches in terms of altering memory > accounting, but SCTP has the notion of accounting buffers based on either > sockets space or association space (based on the sndbuf_policy and rcvbuf_policy > sysctls). This patch eliminates them. I don't see this patch addressing either > the removal of that functionality (as the proposed accounting scheme renders > those sysctls useless and ignored, which may cause regressions in some > environments), nor does it address the possibiliy of one association starving > others on the same socket when they share the same socket level accounting. I > think you need to look how to address that (either by re-adding the ability to > account in either case based on the sysctls, or deprecating eliminating the > sysctls and addressing the starvation issue. That's not how I'm reading these. All original conditions are still there while these patches are adding a couple of restrictions more. What that means is that they are adding a ceiling to it, even if the limits are per socket or per assoc. Considering the idea of the cgroup limit being added here, it makes sense to me. If the cgroup is configured to allow at most X MB, it doesn't matter how that is allocated. That's a sysadmin task then, to adjust the other sysctls (net.sctp.sctp_mem & cia) and balance the usage, be it per socket or per asoc. Cheers, Marcelo