From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f71.google.com (mail-pj1-f71.google.com [209.85.216.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 28B082EA75E for ; Mon, 20 Jul 2026 19:24:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.71 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784575458; cv=none; b=fm1enK1CVar2Wmaa7VUNLP+S4zDRLblXkfHsw1AzmhAo7JbamoAktxU0UFNtUph+mU4fEeetOp63V+9PkthH98xDvnOqh6gkFYk8ZyE3EQwkp70b0PfDTxHCYoWfFoE4MPnuDZEUBjMUw1xWbkQWWkU2UjNaDJMjWP/qIVTmEnA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784575458; c=relaxed/simple; bh=XxBhHRby22DqSpTCBtDzXhPqpJbzVYcSc+NTKD6IsVE=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=c6gsiaEKM4V2BiejCQH6LOYbYzEcsvpQJIfvUw+PWYya0Pu+dmWqz+BjQtfH+5Kx8rt6vdJg0zTMzss09N8OZ76DEGFOoqyvbaUg9ihY5LZXQq3+dCxDJnCGfZX98aeXSB6WkTpF74toKRbQm4M8NK4x7xBWD4k8rgqZfGYqgZ8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--pratmal.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=MxbXCeCD; arc=none smtp.client-ip=209.85.216.71 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--pratmal.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="MxbXCeCD" Received: by mail-pj1-f71.google.com with SMTP id 98e67ed59e1d1-38e8e864ef0so769396a91.0 for ; Mon, 20 Jul 2026 12:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1784575456; x=1785180256; darn=vger.kernel.org; h=content-type:cc:to:from:subject:message-id:references:mime-version :in-reply-to:date:from:to:cc:subject:date:message-id:reply-to :content-type; bh=tr+RxyXd4dPtXqg+ZD5qRc7k0ZVs7iv7vU/1cWUVXKw=; b=MxbXCeCDF7bM5oUapU8GV7SwrG9aWCQtVryIK37yELAfaokR8/HIqKUUAiYNU/pasV pfOnLe5H5eoEUc5SGVwNxQ++r/NTRIwFnXtY6SKn1PRRTzPk5zeJnwGRMmMfix4e9uQw H/ryqAKmPdXietaKPcIW28JLLbPi6rpGpoRi6dmlDWbvr2fa6w8RguHRvPUXgPUalOuJ xsw990HbfAsePkRhHEk7Gj95c3KR1S6MEnf6L1qJPRwSSjlClNiRCO36D5/Q0eyg5+kP CqMYXHZQywFl2lyuVmhsBE3hZtI3y+nI8eUAw17LMyIiVt6zR2DgMgc8Emq36uscG/hJ W43w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784575456; x=1785180256; h=content-type: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:content-type; bh=tr+RxyXd4dPtXqg+ZD5qRc7k0ZVs7iv7vU/1cWUVXKw=; b=FK8bJQtzrDxeqJptI8XAQKnetZZqZq9P6o1I+KBWHAaEt4COx6yYRxhF1ARyWC2SAt MDxXU4miA79Et1De1sq883BJVicR3KybFz93SGnxTbjnTcvjOV2G01ypBe9fNeWcK6Db nXVZYWGkaT4EUTWkcbWmdlHPNONUUuXNifu2DhAQsKK26JqHlVnt1w9qH8cArfrcMBCu LVQ9+IWzT75PkrjTI+1RrErABajaxnuhxhYOQ1YlcYeofgP1Ex63Rm3LZgij8ULZx7d/ NCU8/azfVD/MigOEHBVgJE3H5gR+8dHuAJVL0A6a4aBtSqjSsTcLBNZx920nJZxTQKsk Tjng== X-Forwarded-Encrypted: i=1; AHgh+RpwLGWQ1oWdnQKS6TFk/u0USwDMeWSjqhJ6dL8240wVvuyabIwK5EVZ52tEDh3OJuOnGfEvTBmhy059ki8=@vger.kernel.org X-Gm-Message-State: AOJu0Yx9SQrNA26hQ+Lfjodh1goF8q28bRO2iGEulVbL/noWYCUMuW1X WmzO+HI8zxV1hPDeDdg9kdGDyfRuIld95GQp2EwBihmVzPHOY6Nyz1k8lZ5g8ODpgIz9IlWntVg 2HV0hE+e4TQ== X-Received: from dlbqc12.prod.google.com ([2002:a05:7023:a8c:b0:13b:9778:570]) (user=pratmal job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:c885:b0:380:83fc:4315 with SMTP id 98e67ed59e1d1-38e4b538938mr16800918a91.21.1784575456165; Mon, 20 Jul 2026 12:24:16 -0700 (PDT) Date: Mon, 20 Jul 2026 19:24:15 +0000 In-Reply-To: <03f6d16c-0f1c-4123-abb4-81a73eecaff1@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <03f6d16c-0f1c-4123-abb4-81a73eecaff1@arm.com> X-Mailer: git-send-email 2.55.0.229.g6434b31f56-goog Message-ID: <20260720192415.4060431-1-pratmal@google.com> Subject: Re: [RFC PATCH] mm/page_reporting: Add page_reporting_delay sysctl From: pratmal@google.com To: Anshuman Khandual , David Hildenbrand , Andrew Morton , Vlastimil Babka Cc: Greg Thelen , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" On 7/16/26 02:41, Anshuman Khandual wrote: > On 15/07/26 6:29 PM, David Hildenbrand (Arm) wrote: >> -#define PAGE_REPORTING_DELAY (2 * HZ) >> -static struct page_reporting_dev_info __rcu *pr_dev_info __read_mostly; >> - >> Why are you moving that? > > +1 I wanted the new definitions grouped together, and the sysctl handler has to sit below the enum so it can see PAGE_REPORTING_REQUESTED. But that only constrains where the handler goes, not the declaration. I'll leave pr_dev_info where it was. >> +static unsigned int page_reporting_delay = 2000; >> >> Maybe "2 * MSEC_PER_SEC;" >> >> Would we want to call that page_reporting_delay_ms to make it clearer what we >> are dealing with? > > +1 Agreed on both. I'll rename the sysctl to page_reporting_delay_ms as well in v2. >> +static int page_reporting_delay_sysctl(const struct ctl_table *table, int write, >> + void *buffer, size_t *lenp, loff_t *ppos) >> >> We prefer two tabs here in MM land. Thanks. Will fix this. >> + ret = proc_dointvec(table, write, buffer, lenp, ppos); >> + if (ret < 0 || !write) >> + return ret; >> >> Would we want to cap it at reasonable values? > > Possibly with a macro PAGE_REPORTING_DELAY_MS_MAX or similar. Yes. Will fix this in v2. Will use proc_douintvec_minmax() with a floor and a ceiling (using a new PAGE_REPORTING_DELAY_MS_MAX macro). >> + rcu_read_lock(); >> + prdev = rcu_dereference(pr_dev_info); >> + if (prdev && atomic_read(&prdev->state) == PAGE_REPORTING_REQUESTED) >> + mod_delayed_work(...); >> + rcu_read_unlock(); >> >> Is that really required? Seems unnecessary given that we expect something in the >> range of a couple of seconds max. > > Agreed. Our use case is that the delay isn't static. A daemon in the guest watches for host memory pressure and drops the delay to expedite reporting, then raises it again once the pressure clears. The delay can be tens of seconds when we're absorbing churn, so waiting out the current window defeats the purpose of the dynamic adjustment. Apologies, I should have clarified this in the original commit message. I'm happy to drop it or decouple this triggering behavior from the tuning behavior. We could probably create a separate sysctl to manually trigger the reporting instead. Thanks to both of you for the review. Pratyush Mallick.