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 D8996C433EF for ; Thu, 19 May 2022 18:23:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 101186B0071; Thu, 19 May 2022 14:23:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0B14C6B0072; Thu, 19 May 2022 14:23:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB9AE6B0073; Thu, 19 May 2022 14:23:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D95216B0071 for ; Thu, 19 May 2022 14:23:27 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id ABC6933D9A for ; Thu, 19 May 2022 18:23:27 +0000 (UTC) X-FDA: 79483315254.28.EA5EF3C Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by imf16.hostedemail.com (Postfix) with ESMTP id 5507618000A for ; Thu, 19 May 2022 18:23:15 +0000 (UTC) Received: by mail-wr1-f47.google.com with SMTP id u3so8361423wrg.3 for ; Thu, 19 May 2022 11:23:27 -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=69aaD4QPBI9GdAKDBus5t7k/zTxSvsdipve2TR2Ob64=; b=GkrWqpjb2yzPqkTVz9B3AF1h6LM7P8OXxi4jhC4daSBHKirsPkAj/SnhCBRObr6hEA WiRe4Wva0Ozk3jVncq2kBHskGsms1JYwqHmXoWzPjEPybLXpd46qdKbASSPGfdxi63vy LJQH7E7ZG4EQo1NMjCDQ0C21BbsohR5OpwSvd5tXaRitjNYoejlK5W2ozBG9NWI+9HsO 5EE6MfloqEZZ2bWuw2IDjRbqk6NiHnUWnmQgkFaiD6UyO98KHexuzXwqXY6gYRjB37Lv EhtgEtqHenGlbGslS2t3DXNV3YJTqWgMMvu0VwKxEOxEdNtIkE+6JtzxqyJGaKb+J7tA hXMA== 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=69aaD4QPBI9GdAKDBus5t7k/zTxSvsdipve2TR2Ob64=; b=sPAD16cT9V7SM9b4YOVC1eFONDoSOxU6IhITncwTVJG3YSashdeVQiKUbtxXw4K/Yi 3hBqbKGsS9vdP+spkQyWiS6x5vgTmxZXqducG0of53/DG3tGQo/gHC3MqU/kDZHUI1+T srcRvVjWdfUaKrSqUZpklLHpWsTJIrUWFPaqTt4t+zUMVs7NFOIoZlpfBdEPCP7qZNFk O2Zj929ylnN4C5lvyaDNfhutrOpf8/1NW0o7SIJZvnup3THalKWgN9OdkejT15tch0vS iN6Lo6ugp08bVtt9LO8MIm/eVXAJ4f5NZKgD2zoRySPmlJTr48/jJQa7rMYYhnHKs1cR qqnQ== X-Gm-Message-State: AOAM532oKwrSnKzBTtTCbfYmDlatrUncuZF5uFwr7xhtCyABOk9lTds8 ceEFZxyPnKcKKv9IQpdjglWCtXcf+gzO4Rh+5P1OuQ== X-Google-Smtp-Source: ABdhPJzgiRnXFN6S2gC1fKKXjzhLgZufzaMOa157G/FFVNR/qTjRPbeyyLcMCUrWvBY7gjwJ1/H59Sfaq//qqD7qEOk= X-Received: by 2002:adf:fb05:0:b0:20a:e113:8f3f with SMTP id c5-20020adffb05000000b0020ae1138f3fmr5325035wrr.534.1652984605773; Thu, 19 May 2022 11:23:25 -0700 (PDT) MIME-Version: 1.0 References: <20220518223815.809858-1-vaibhav@linux.ibm.com> <878rqxhpn1.fsf@vajain21.in.ibm.com> In-Reply-To: <878rqxhpn1.fsf@vajain21.in.ibm.com> From: Yosry Ahmed Date: Thu, 19 May 2022 11:22:49 -0700 Message-ID: Subject: Re: [PATCH] memcg: provide reclaim stats via 'memory.reclaim' To: Vaibhav Jain Cc: cgroups@vger.kernel.org, linux-doc@vger.kernel.org, Linux Kernel Mailing List , Linux-MM , Tejun Heo , Zefan Li , Johannes Weiner , Jonathan Corbet , Michal Hocko , Vladimir Davydov , Andrew Morton , "Aneesh Kumar K . V" , Shakeel Butt Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 5507618000A X-Stat-Signature: qyngwmoe6mokje399dbknhdb8hpstrx4 X-Rspam-User: Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GkrWqpjb; spf=pass (imf16.hostedemail.com: domain of yosryahmed@google.com designates 209.85.221.47 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1652984595-416571 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, May 19, 2022 at 1:51 AM Vaibhav Jain wrote: > > Hi, > > Thanks for looking into this patch, > > Yosry Ahmed writes: > > > On Wed, May 18, 2022 at 3:38 PM Vaibhav Jain wrote: > >> > >> [1] Provides a way for user-space to trigger proactive reclaim by introducing > >> a write-only memcg file 'memory.reclaim'. However reclaim stats like number > >> of pages scanned and reclaimed is still not directly available to the > >> user-space. > >> > >> This patch proposes to extend [1] to make the memcg file 'memory.reclaim' > >> readable which returns the number of pages scanned / reclaimed during the > >> reclaim process from 'struct vmpressure' associated with each memcg. This should > >> let user-space asses how successful proactive reclaim triggered from memcg > >> 'memory.reclaim' was ? > > > > Isn't this a racy read? struct vmpressure can be changed between the > > write and read by other reclaim operations, right? > Read/write of vmpr stats is always done in context of vmpr->sr_lock > which is also the case for this patch. So not sure how the read is racy > ?. I didn't mean that you can read the value while it is being changed. I meant that between writing to memory.reclaim and reading from it, another reclaim operation could modify memcg vmpressure. A sequence like this: 1) Write to memory.reclaim 2) Kernel coincidentally runs reclaim on that memcg 3) Read from memory.reclaim The result would be that you are reading the stats of another reclaim operation, not the one invoked by writing to memory.reclaim. > > > > > I was actually planning to send a patch that does not updated > > vmpressure for user-controller reclaim, similar to how PSI is handled. > > > Ok, not sure if I am inferring correctly as to how how that would be > useful. Can you please provide some more context. IIUC vmpressure is used as an indicator for memory pressure. In my opinion it makes sense if vmpressure is not changed on reclaim operations directly invoked by the user, as they are not directly related to whether the system is under memory pressure or not. PSI is handled in a similar way. See e22c6ed90aa9 ("mm: memcontrol: don't count limit-setting reclaim as memory pressure"). > > The primary motivation for this patch was to expose the vmpressure stats > to user space that are available with cgroup-v1 but not with cgroup-v2 > AFAIK If the main goal is exposing vmpressure, regardless of proactive reclaim, this is something else. AFAIK vmpressure is not popular anymore and PSI is the more recent/better indicator. > > > The interface currently returns -EBUSY if the entire amount was not > > reclaimed, so isn't this enough to figure out if it was successful or > > not? > Userspace may very well want to know the amount of memory that was > partially reclaimed even though write to "memory.reclaim" returned > '-EBUSY'. This feedback can be useful info for implementing a retry > loop. > > > If not, we can store the scanned / reclaim counts of the last > > memory.reclaim invocation for the sole purpose of memory.reclaim > > reads. > Sure sounds reasonable to me. > > > Maybe it is actually more intuitive to users to just read the > > amount of memory read? In a format that is similar to the one written? > > > > i.e > > echo "10M" > memory.reclaim > > cat memory.reclaim > > 9M > > > Agree, I will address that in v2. > > > > -- > Cheers > ~ Vaibhav