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 1E622C433EF for ; Fri, 24 Jun 2022 22:10:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 864248E0279; Fri, 24 Jun 2022 18:10:54 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8125C8E0244; Fri, 24 Jun 2022 18:10:54 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DAFD8E0279; Fri, 24 Jun 2022 18:10:54 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5D7E68E0244 for ; Fri, 24 Jun 2022 18:10:54 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2E0D520D27 for ; Fri, 24 Jun 2022 22:10:54 +0000 (UTC) X-FDA: 79614525228.20.CA20FE1 Received: from mail-yw1-f180.google.com (mail-yw1-f180.google.com [209.85.128.180]) by imf24.hostedemail.com (Postfix) with ESMTP id CD993180025 for ; Fri, 24 Jun 2022 22:10:53 +0000 (UTC) Received: by mail-yw1-f180.google.com with SMTP id 00721157ae682-317a66d62dfso37207637b3.7 for ; Fri, 24 Jun 2022 15:10:53 -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=MPUT7b82LF4hqDUUtgfdWYg7XHkm0MfnLKUixSkaz7k=; b=WnBDdY1sKHZ43lWqKHRdAuYvybd/8kSb8TjkZR2KOTjX+5fZb8SKXr70R8vn/Nm6uk yy4AZjujv1MOQ5qE2LXrfnBKvSwrWHTd+o3nonjwTNHkV7um3J8BSZL7ce36KLQ2EZgg lfUXVN9saCk3H6SQLSe4zS4iFH8wJseir8mwv6IN1oJDaxd8zJt5GHB3m1qxUpL7EEdS 0WSlfRFS3DcyX+dYA06LrxbMRqCjvo+gegjH7Rm50Z6JkIqTm6Qw8Vk3VMpGxXEEsGHY 3NWLPplEPK76M2TowCn8uxsEhEV2i1ID5pLJpgrCXm3/ymUus4LDoeK9Zq01HuUBqIPr Ot/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=MPUT7b82LF4hqDUUtgfdWYg7XHkm0MfnLKUixSkaz7k=; b=ThycrlqDV/DzE7fi4P2ROHTL+wAiMU3xycrTdjezHjdXpy6PhRMyMlJTaW9Svkux7e MJ9ko408P91hGX+JeOhKPFWkA70l8vdWUW+s+s6/uJo3G3VkD2ex/yrnklDLCkXrvO0x IKa7ZHvVpvXtoEM0+fy2EYcyNZcJ741KOIHkD2tBwIBJM/bmMgcw2oAeNkXkFr1qbWSU 1LLsp2GCOPoqMdvcVYdujTUV6vM0nD68BXtrwep4NHeMu68+hwWkIMpYEDfeKsouXMa6 1Tf5Z7za5FpX9CV7i3rf9kvrBMFpKa/Wsi0rPlnGiIgge4L9LVXswhd8ZRmj4jPfeEm0 mQEg== X-Gm-Message-State: AJIora+xb4Lyow0+WokpDlcvXG63uhVL0nHJcPRRdW9WbQNjT+QkjtFU uRL0QuOHQQ7CZCmRMsMAk4I1oxKZDCfe6M3up/LLjg== X-Google-Smtp-Source: AGRyM1sxAxV70UIIWovLfc+/KoZfgfG1H160vS226s5+FEkGtuxLMGsy88z4J48RiBrNZTyFJb70K7XvMmCwJTSSeXw= X-Received: by 2002:a81:990f:0:b0:2f8:c347:d11a with SMTP id q15-20020a81990f000000b002f8c347d11amr1212049ywg.507.1656108652897; Fri, 24 Jun 2022 15:10:52 -0700 (PDT) MIME-Version: 1.0 References: <20220623000530.1194226-1-yosryahmed@google.com> In-Reply-To: From: Suren Baghdasaryan Date: Fri, 24 Jun 2022 15:10:42 -0700 Message-ID: Subject: Re: [PATCH] mm: vmpressure: don't count userspace-induced reclaim as memory pressure To: Yosry Ahmed Cc: Michal Hocko , Shakeel Butt , Johannes Weiner , Roman Gushchin , Muchun Song , Andrew Morton , Matthew Wilcox , Vlastimil Babka , David Hildenbrand , Miaohe Lin , NeilBrown , Alistair Popple , Peter Xu , Linux Kernel Mailing List , Cgroups , Linux-MM Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656108653; 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=MPUT7b82LF4hqDUUtgfdWYg7XHkm0MfnLKUixSkaz7k=; b=SlmG0CYxhO1hRsaTNmy0cFxzQY7pdxEtTbVn2FBFgCo8xQ3kDDgu1vo6RwUpBIZ4sjR11p lFCqv1sCQDQdnM/ymA9zzMNZIpif6h13y5QpFUGlv2g+cSbUgXlR7TjLKNvJp7VppsrZKj lfbhOndBnvhEtoL9ecJnWsDl/BD754s= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WnBDdY1s; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656108653; a=rsa-sha256; cv=none; b=HmxLIlYgsK9foDum59jsnn5b3hDAgiwAxEB8e1rTIifv9S/1/kPgT+W9El81IoKxLdGhFv G/mL9Yg5BidzsA5KfWRair4E8UcVVRFuG7bN3qTPyy5p42hpeFcHMgpjozmehYxNjARCsH 7cswQDqkAmQiILeVBS9dNsilNcGYQRI= X-Rspamd-Queue-Id: CD993180025 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=WnBDdY1s; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf24.hostedemail.com: domain of surenb@google.com designates 209.85.128.180 as permitted sender) smtp.mailfrom=surenb@google.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: ndbecszwbwg6w5etr4cp6e5katmf6k3o X-HE-Tag: 1656108653-335070 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, Jun 23, 2022 at 10:26 AM Yosry Ahmed wrote: > > On Thu, Jun 23, 2022 at 10:04 AM Michal Hocko wrote: > > > > On Thu 23-06-22 09:42:43, Shakeel Butt wrote: > > > On Thu, Jun 23, 2022 at 9:37 AM Michal Hocko wrote: > > > > > > > > On Thu 23-06-22 09:22:35, Yosry Ahmed wrote: > > > > > On Thu, Jun 23, 2022 at 2:43 AM Michal Hocko wrote: > > > > > > > > > > > > On Thu 23-06-22 01:35:59, Yosry Ahmed wrote: > > > > [...] > > > > > > > In our internal version of memory.reclaim that we recently upstreamed, > > > > > > > we do not account vmpressure during proactive reclaim (similar to how > > > > > > > psi is handled upstream). We want to make sure this behavior also > > > > > > > exists in the upstream version so that consolidating them does not > > > > > > > break our users who rely on vmpressure and will start seeing increased > > > > > > > pressure due to proactive reclaim. > > > > > > > > > > > > These are good reasons to have this patch in your tree. But why is this > > > > > > patch benefitial for the upstream kernel? It clearly adds some code and > > > > > > some special casing which will add a maintenance overhead. > > > > > > > > > > It is not just Google, any existing vmpressure users will start seeing > > > > > false pressure notifications with memory.reclaim. The main goal of the > > > > > patch is to make sure memory.reclaim does not break pre-existing users > > > > > of vmpressure, and doing it in a way that is consistent with psi makes > > > > > sense. > > > > > > > > memory.reclaim is v2 only feature which doesn't have vmpressure > > > > interface. So I do not see how pre-existing users of the upstream kernel > > > > can see any breakage. > > > > > > > > > > Please note that vmpressure is still being used in v2 by the > > > networking layer (see mem_cgroup_under_socket_pressure()) for > > > detecting memory pressure. > > > > I have missed this. It is hidden quite good. I thought that v2 is > > completely vmpressure free. I have to admit that the effect of > > mem_cgroup_under_socket_pressure is not really clear to me. Not to > > mention whether it should or shouldn't be triggered for the user > > triggered memory reclaim. So this would really need some explanation. > > vmpressure was tied into socket pressure by 8e8ae645249b ("mm: > memcontrol: hook up vmpressure to socket pressure"). A quick look at > the commit log and the code suggests that this is used all over the > socket and tcp code to throttles the memory consumption of the > networking layer if we are under pressure. > > However, for proactive reclaim like memory.reclaim, the target is to > probe the memcg for cold memory. Reclaiming such memory should not > have a visible effect on the workload performance. I don't think that > any network throttling side effects are correct here. IIUC, this change is fixing two mechanisms during userspace-induced memory pressure: 1. psi accounting, which I think is not controversial and makes sense to me; 2. vmpressure signal, which is a "kinda" obsolete interface and might be viewed as controversial. I would suggest splitting the patch into two, first to fix psi accounting and second to fix vmpressure signal. This way the first one (probably the bigger of the two) can be reviewed and accepted easily while debates continue on the second one. > > > > > > Though IMO we should deprecate vmpressure altogether. > > > > Yes it should be really limited to v1. But as I've said the effect on > > mem_cgroup_under_socket_pressure is not really clear to me. It really > > seems the v2 support has been introduced deliberately. > > > > -- > > Michal Hocko > > SUSE Labs