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 D6400EEAA71 for ; Thu, 14 Sep 2023 21:20:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229729AbjINVUz (ORCPT ); Thu, 14 Sep 2023 17:20:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46044 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229764AbjINVUt (ORCPT ); Thu, 14 Sep 2023 17:20:49 -0400 Received: from mail-yw1-x114a.google.com (mail-yw1-x114a.google.com [IPv6:2607:f8b0:4864:20::114a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9ADE52703 for ; Thu, 14 Sep 2023 14:20:45 -0700 (PDT) Received: by mail-yw1-x114a.google.com with SMTP id 00721157ae682-5925fb6087bso18420387b3.2 for ; Thu, 14 Sep 2023 14:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1694726445; x=1695331245; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=ob3uAvnOoSCrtCSZPkBDgY1akrbFBa78/VkbR/tD3Zk=; b=vOINow2YxM/MoSfukFZ+ffrZCGQymL1/8iS4WZMKdLIOjR5lWXaAC7A8DVAmDEuYSJ eVarJzpkG9cb+yEJ9ex8zSMdTP5BIxrCgLWVUJJWm+nuz4cuaxe6+ZKRFxf/vuDP1AOO Igxca97ZL1BJEgGVbJBDmAIu0+JF09MnlKp6LA4bb0yCKyk2vm8FTWyHVMQMx9bOhPcL RSJJwqI4cdBz7jr8JUBRzH3DJyaHjtl9/2b0Lfn4Yw3Hwn94ZF/Ci2oKsJGaHvOIgZhr HBhFoU6klN3eTC3QkiE+S58oOHd42DD4sL/C3/mvDNXWdPBu0fIcFFFyGOo3BC7IHyRy GU6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694726445; x=1695331245; 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=ob3uAvnOoSCrtCSZPkBDgY1akrbFBa78/VkbR/tD3Zk=; b=dJQKJgsVva0FbeJZkO46v4GrBdsLrUZSnsi/kb61vyg2poq5+9qLXtp3fS48aWJYiz QPcG0Ux0noZxgcv/HeWqxU2z+Ny+G7OV+G8U8JiHknpisAcwak3p4+9eRDX0uyLjQe3x wUR8xewO1x08zJU+6bMDoHviW1XHDxU5LCo8dnRQWYmVIfxOlSiIy2Q3+GmaU9WPBLh/ Gijpti7UFTYJbyncNeHYtmAoZ5CKtgmxkHrxC0YvPx568n2ajuRQ4gaqZLns9bJ4N1xC wMY5WN1nVO8Ek7GJysFoY3TS1pbP9M7ic1haxN1ENWuIPKmjPXBFKUMW35xSAaLlFCN5 kGWQ== X-Gm-Message-State: AOJu0YwHy6ayyfhkn8cxJioWh3Hp1wHRsLZ+WPFwqJsCHeBd0QIqBH2r Rz3UUHI32udJQPwCE8klSNWPVdoKm598Kw== X-Google-Smtp-Source: AGHT+IHqKkwRb4VbopLin6Ia5XmxbD4rC+NeBFNXt+55ae4VdsIBmIxgGh8mmlngX1m+Fr0aiJb37+HMAskv5w== X-Received: from shakeelb.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:262e]) (user=shakeelb job=sendgmr) by 2002:a81:af11:0:b0:565:9bee:22e0 with SMTP id n17-20020a81af11000000b005659bee22e0mr176595ywh.0.1694726444854; Thu, 14 Sep 2023 14:20:44 -0700 (PDT) Date: Thu, 14 Sep 2023 21:20:42 +0000 In-Reply-To: <20230901062141.51972-1-wuyun.abel@bytedance.com> Mime-Version: 1.0 References: <20230901062141.51972-1-wuyun.abel@bytedance.com> Message-ID: <20230914212042.nnubjht3huiap3kk@google.com> Subject: Re: [RFC PATCH net-next 0/3] sock: Be aware of memcg pressure on alloc From: Shakeel Butt To: Abel Wu Cc: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Andrew Morton , Roman Gushchin , Michal Hocko , Johannes Weiner , Yosry Ahmed , "Matthew Wilcox (Oracle)" , Yu Zhao , Kefeng Wang , Yafang Shao , Kuniyuki Iwashima , Martin KaFai Lau , Breno Leitao , Alexander Mikhalitsyn , David Howells , Jason Xing , open list , "open list:NETWORKING [GENERAL]" , "open list:MEMORY MANAGEMENT" Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 01, 2023 at 02:21:25PM +0800, Abel Wu wrote: > [...] > As expected, no obvious performance gain or loss observed. As for the > issue we encountered, this patchset provides better worst-case behavior > that such OOM cases are reduced at some extent. While further fine- > grained traffic control is what the workloads need to think about. > I agree with the motivation but I don't agree with the solution (patch 2 and 3). This is adding one more heuristic in the code which you yourself described as helped to some extent. In addition adding more dependency on vmpressure subsystem which is in weird state. Vmpressure is a cgroup v1 feature which somehow networking subsystem is relying on for cgroup v2 deployments. In addition vmpressure acts differently for workloads with different memory types (mapped, mlocked, kernel memory). Anyways, have you explored the BPF based approach. You can induce socket pressure at the points you care about and define memory pressure however your use-case cares for. You can define memory pressure using PSI or vmpressure or maybe with MEMCG_HIGH events. What do you think? thanks, Shakeel