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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47F68C433EF for ; Thu, 21 Jul 2022 16:49:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 77B658E0001; Thu, 21 Jul 2022 12:49:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 72E366B0072; Thu, 21 Jul 2022 12:49:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5F39B8E0001; Thu, 21 Jul 2022 12:49:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4FD8D6B0071 for ; Thu, 21 Jul 2022 12:49:51 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 14725AB362 for ; Thu, 21 Jul 2022 16:49:51 +0000 (UTC) X-FDA: 79711693782.05.2149C34 Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf02.hostedemail.com (Postfix) with ESMTP id A6D2B80058 for ; Thu, 21 Jul 2022 16:49:50 +0000 (UTC) Received: by mail-wm1-f43.google.com with SMTP id u14-20020a05600c00ce00b003a323062569so1136664wmm.4 for ; Thu, 21 Jul 2022 09:49:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RdUUQLWwQt1lokFjpVxfgBDqZBmrvlIq3f9uYET+tvs=; b=GY5wu9Q/FEgr1xnB2EhxJuzovNWJwL4CbpjQ4mge6mweV3qC/mZ0X2IJ4qIMHbUUAG UAvCXBjfOz56dmlgiKQ40A8WYTaPIowbBSTxq8HYzTMdNas7AZ66zJ79UC4oYn9KQko5 Wyn061wupTIFwzmtENvE6UeJ5MCktaVrRDbnpP56MexcUXHFft4o+C/Amwpp9RiqCt7w r8rjXuOIrINJLUX4LbvxHTzwEb+a00CsAJzmE2PBDL9EEpSSEIAR2/46he8lpjR23dPa Jn1nOFUTWXgYcS6hT4+jq4SrRLsflQkzCKKbYVtnUMDDM7Kio/t61r+yB0bYBIBEMz3Q 2s/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RdUUQLWwQt1lokFjpVxfgBDqZBmrvlIq3f9uYET+tvs=; b=Yn/SPqDqMHpdBnzH88MUytQo+lrXIHRziSSNLjHhqnd0trRcx5CKAw3W0+dXshIcdt KBTCaBJh2Um9t3+/pZ7nm3K2W2dbZU3XwAr/lxRRrJmtPOMi5sUUnxB7GTVIrSzjj5FW /boGgJADeC8YQScsS6ycTfHj7Kd9qBjb8e0jXilz0GchvYfH5NY1rJqM6fvVqS/4hN1R KXS/FzFLarbBnUC1YcbGn7zKlC+cSNVBB1CPTIokLEb0vcWiLmkZVBtryoAtAwcwGaoL F6L+8p9Rk4hJcHpPDptLlEsSM85hdCr/drh08zyKKLXpfza3tbbolV8NqYbVwsC2vZRC hElQ== X-Gm-Message-State: AJIora+bGcMMGhkf+2m3JTyP+VDzCAsCtdibbYRofJfWAtsIfIsIHJHC FYIDLcYYLG18tldg+NmMnxwUPrHE/NqrYryja+xnPw== X-Google-Smtp-Source: AGRyM1uueYuywQlzFF79QTrzJABzxA9oBvmvm72bRPUCr6v3SC49VU6rYoQLotGaJGSdOVt7/FOJ/SgaBNAk+1wOFj4= X-Received: by 2002:a7b:c85a:0:b0:3a3:1884:6391 with SMTP id c26-20020a7bc85a000000b003a318846391mr9132955wml.196.1658422189317; Thu, 21 Jul 2022 09:49:49 -0700 (PDT) MIME-Version: 1.0 References: <20220714064918.2576464-1-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 21 Jul 2022 09:49:12 -0700 Message-ID: Subject: Re: [PATCH v4] mm: vmpressure: don't count proactive reclaim in vmpressure To: Michal Hocko Cc: Shakeel Butt , Johannes Weiner , Roman Gushchin , Muchun Song , Andrew Morton , Matthew Wilcox , Vlastimil Babka , David Hildenbrand , Miaohe Lin , NeilBrown , Alistair Popple , Suren Baghdasaryan , Peter Xu , LKML , Cgroups , Linux MM Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658422190; a=rsa-sha256; cv=none; b=bhA3F1fBXlg7YjycSi/SAVu0ThOmCO43/yYM/KP5Os/QpSO51SPElXK44tvIN9pV7ESTIQ nnKz6t7X6VygfohLxUS+Q+2xOqEs4kCdQ0PotXH9KkLJLxZpyVMFC35nY4oF9glDZDy051 ACLsooP1qVOPIJ/0zm3YcXwJCvbGh2w= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="GY5wu9Q/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of yosryahmed@google.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658422190; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=RdUUQLWwQt1lokFjpVxfgBDqZBmrvlIq3f9uYET+tvs=; b=BUJqVVkWBImvPzhs+hdI/TIi6nfhuM3AtAdKEO8o5SxMeZPjVQcnxBgp2GDrbV02ZgIrf5 K07q7NHKaVkLmgwWP4hKXwh9lC/O+papV4muCz2lThgmmaD7Dq4vkdbqsZlZm2NRTfSzsF s0EnpWkaogemi2UeLHm5jFnTZNpjX2M= Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b="GY5wu9Q/"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf02.hostedemail.com: domain of yosryahmed@google.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=yosryahmed@google.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: A6D2B80058 X-Stat-Signature: z9iwa7uruxrkw9mdmn8g9tibzk3a6uie X-Rspam-User: X-HE-Tag: 1658422190-25669 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jul 21, 2022 at 9:42 AM Michal Hocko wrote: > > On Thu 21-07-22 08:58:06, Yosry Ahmed wrote: > > On Thu, Jul 21, 2022 at 4:44 AM Michal Hocko wrote: > > > > > > On Wed 20-07-22 11:02:56, Yosry Ahmed wrote: > > > > On Wed, Jul 20, 2022 at 10:50 AM Shakeel Butt wrote: > > > > > > > > > > On Wed, Jul 20, 2022 at 2:24 AM Michal Hocko wrote: > > > > > > > > > > > [...] > > > > > > > > > > > > I think what we are missing here is > > > > > > - explain that this doesn't have any effect on existing users of > > > > > > vmpressure user interface because that is cgroup v1 and memory.reclaim > > > > > > is v2 feature. This is a trivial statement but quite useful for future > > > > > > readers of this commit > > > > > > - explain the effect on the networking layer and typical usecases > > > > > > memory.reclaim is used for currently and ideally document that. > > > > > > > > > > I agree with the above two points (Yosry, please address those) but > > > > > the following third point is orthogonal and we don't really need to > > > > > have an answer for this patch to be accepted. > > > > > > > > > > > > > That's great feedback, thanks Michal and Shakeel! > > > > > > > > How do you feel about the following commit message instead? Does it > > > > address your concerns?: > > > > > > > > memory.reclaim is a cgroup v2 interface that allows users to > > > > proactively reclaim memory from a memcg, without real memory pressure. > > > > Reclaim operations invoke vmpressure, which is used in cgroup v1 to > > > > notify userspace of reclaim efficiency, and used in both v1 and v2 as > > > > a signal for a memcg being under memory pressure for networking (see > > > > mem_cgroup_under_socket_pressure()). For the former, vmpressure > > > > notifications in v1 are not affected by this change since > > > > memory.reclaim is a v2 feature. > > > > > > > > For the latter, the effects of the vmpressure signal (according to > > > > Shakeel [1]) are as follows: > > > > 1. Reducing send and receive buffers of the current socket. > > > > 2. May drop packets on the rx path. > > > > 3. May throttle current thread on the tx path. > > > > > > > > Since proactive reclaim is invoked directly by userspace, not by > > > > memory pressure, it makes sense not to throttle networking. Hence, > > > > this change makes sure that proactive reclaim caused by memory.reclaim > > > > does not trigger vmpressure. > > > > > > OK, looks much better. Please also add a note to the documentation about > > > this side effect. > > > > I don't want to add something to the documentation about throttling > > networking because it seems like these are implementation details that > > we may change in the future. I don't know if we can document this > > behavior today and then change it later. > > The exact mechanism on how the throttling is done is one thing. This can > change. But the fact that _no_ throttling is applied is something that > we shouldn't change of course. If we were really strict we shouldn't > change it even now but considering that the interface is new and > usecases still shaping then better now than later. > > > How about we document a more generic statement in memory.reclaim > > documentation, like: > > > > "With reactive reclaim operations triggered by the kernel, the kernel > > may take further actions to alleviate memory pressure (such as > > throttling networking memory consumption). For proactive reclaim > > operations triggered by this interface, the kernel may choose to skip > > such actions as reclaim is not an indication of memory pressure." > > IDK, this sounds too much word lawyering to me TBH. It is better to be clear > about explicitly known side effects. For example where do shrinkers > stand in the light of above wording? Kernel can chose to do almost > anything and I do not think we want to control which shrinkers are > triggered and what they do. > > So I would really prefer to say something like: > " > Please note that the proactive reclaim (triggered by this interface) is > not meant to indicate memory pressure on the memory cgroup. Therefore > socket memory balancing triggered by the memory reclaim normally is not > exercised in this case. This means that the networking layer will not > adapt based on reclaim induced by memory.reclaim. > " Sounds good to me! Will send v5 shortly with added doc changes and the newly agreed upon commit log. Thanks Michal! > -- > Michal Hocko > SUSE Labs