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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30E3BC4332F for ; Mon, 5 Dec 2022 19:33:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234333AbiLETdh (ORCPT ); Mon, 5 Dec 2022 14:33:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34164 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234271AbiLETdS (ORCPT ); Mon, 5 Dec 2022 14:33:18 -0500 Received: from mail-pg1-x549.google.com (mail-pg1-x549.google.com [IPv6:2607:f8b0:4864:20::549]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EBEE827FFB for ; Mon, 5 Dec 2022 11:28:16 -0800 (PST) Received: by mail-pg1-x549.google.com with SMTP id p7-20020a631e47000000b0047691854a86so10587352pgm.16 for ; Mon, 05 Dec 2022 11:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=t2eV37n1EV50KN4L5BF+kL5AM4qRwzFeAkejJliXYvE=; b=OXixcqr3xZZ9Hudft/Jy24A4UlcW/Yb6EPf+E30B+Y3SrNhoNoQK+pCDrL/PMBDL82 IKcAOaMUGYH18Gh0odJqUTEELnNAropoi9gMTbXzIRbC6SljHGZd+rT95xqsGFvPic/v sTqJEV88g2wzK30Nz1wYLyY6DgGQm7B8iNTPT1bVcf6ZiPyuFIGsvVEKRmmfY1gdc5xm 9MA2j56JA5130vszUlvLjOLBg1AOC0touX+NmNhzcvJ20NgsWpDoctpN+DZtaHkTWw+x l6O4Rzr7mT+phIJg/gOMUY7jYqiscVkkTUPHYdYGsO2cFfNeKeOJ/nb0kIBvUXlCC+kj Uwuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=t2eV37n1EV50KN4L5BF+kL5AM4qRwzFeAkejJliXYvE=; b=7g2Su1nlPuZHbRy06Vj3YHQXb8KG/HUtpyWU34pesW8rlUgQRQEhNkXDaIRgQZLxzl 38pUxPjqWzPY/6nYz85Xplgk3F/6EsGzPYCKBTOxG02GcQoZw638nXGgZAUZKL7ZtU/8 k2vrMHG1fb2m6cZ+CWrVFooABfNmC0CeWcIqahX+hxyC43UyqXcc2mFGZVX3YgCxIFdX k4FqQcx7wudLTYDPWwD+Ia/Cz/ZTmAENf6Q+KDzcu3lcPjkQiExHd6DJJ6n/935XUkRh qe39GOE99JQgxeNwbzmgB4disQdGn6psJxM1HqI6qvtTbNhk9sCwPiOa4d33WPhDRixL NzRw== X-Gm-Message-State: ANoB5pn26K1NrPa6YTtGLKAgZg+x+ctILBFm4OvDP4qIFHcQZQVlIXdD UGZS//xeAR/k4b2IEC8MLmn2qrset5lHqA== X-Google-Smtp-Source: AA0mqf5iSLEojI6ymm5KY4Cvy/sEXpzhv0X25vL6jTq1Tlafmy0Z146Re+y1UCBZXZ4Atx9lOXv0PbiZWzYBTQ== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a17:90a:c006:b0:219:158d:b19a with SMTP id p6-20020a17090ac00600b00219158db19amr51964448pjt.152.1670268496206; Mon, 05 Dec 2022 11:28:16 -0800 (PST) Date: Mon, 5 Dec 2022 19:28:14 +0000 In-Reply-To: Mime-Version: 1.0 References: Message-ID: <20221205192814.diiwtktsrgxzccw2@google.com> Subject: Re: Low TCP throughput due to vmpressure with swap enabled From: Shakeel Butt To: Johannes Weiner Cc: Ivan Babrou , Linux MM , Linux Kernel Network Developers , linux-kernel , Michal Hocko , Roman Gushchin , Muchun Song , Andrew Morton , Eric Dumazet , "David S. Miller" , Hideaki YOSHIFUJI , David Ahern , Jakub Kicinski , Paolo Abeni , cgroups@vger.kernel.org, kernel-team Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 28, 2022 at 01:07:25PM -0500, Johannes Weiner wrote: > [...] > > With the patch applied I'm capped at ~120MB/s, which is a symptom of a > > clamped window. > > > > I can't find any sockets with memcg->socket_pressure = 1, but at the > > same time I only see the following rcv_ssthresh assigned to sockets: > > Hm, I don't see how socket accounting would alter the network behavior > other than through socket_pressure=1. > I think what is happening is that the tcp stack is calling tcp_under_memory_pressure() and making decisions without going through the memcg charge codepath which set or reset memcg->socket_pressure. Most probably the socket is clamped due to memcg->socket_pressure and then the kernel never tried to grow its buffers because memcg->socket_pressure is still set and thus never tried the memcg charge codepath which would have reset memcg->socket_pressure. (Maybe) That is my guess but network experts CCed can correct me. Anyways, I don't think the pressure mechanism which relies on successful charging will work. I am brainstorming towards memory.high based network throttling. Basically use penalty_jiffies (or something similar) to set memcg->socket_pressure. However I want this to be opt-in as we do have applications which prefer to be killed than be throttled. So, still working on the fine details how this can be done without introducing a rigid API.