All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Benjamin Lee McQueen <mcq@disroot.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v3] mm/vmpressure: scale window size based on machine memory
Date: Thu, 12 Mar 2026 08:18:57 +0100	[thread overview]
Message-ID: <abJo4YQLucQ8zOdM@tiehlicka> (raw)
In-Reply-To: <31c4680848b833d53b1979b45d5a368d@disroot.org>

On Fri 06-03-26 17:44:08, Benjamin Lee McQueen wrote:
> On 2026-03-06 16:52, Michal Hocko wrote:
> > On Wed 04-03-26 22:30:38, Benjamin Lee McQueen wrote:
> >> the vmpressure window size has been fixed at 512 pages
> >> (SWAP_CLUSTER_MAX * 16), ever since the file's inception. a TODO in
> >> the file notes that the vmpressure window size should be scaled
> >> similarly to vmstat's scaling, via machine size.
> >> 
> >> the problem with fixed window size on large memory systems:
> > 
> > Thank you for this much more detail insight into your thinking. This is
> > a good start. I am still missing an overall motivation though. Are you
> > trying to address a theoretical concern (the said TODO) or do you have
> > any practical workload that generates bogus vmpressure events. 
> 
> yes, as i don't personally have a workload that explicitly requires
> vmpresssure to not generate bogus events, it is still technically a "bug"
> that can still be improved.  i believe many legacy systems would benefit
> from this as they still use vmpressure notifications.

I believe we need some real workloads that have very strong reason to
not move to PSI and need this to justify any change in this area.
 
> i agree PSI is the preferred interface, but vmpressure is still used in
> other production environments, like Android's LMKD, right?
> 
> -ben

-- 
Michal Hocko
SUSE Labs


  reply	other threads:[~2026-03-12  7:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-27 22:15 [PATCH] mm/vmpressure: scale window size based on machine memory and CPU count Benjamin Lee McQueen
2026-03-02  8:56 ` Michal Hocko
2026-03-02 12:15   ` Lorenzo Stoakes
2026-03-05  4:30     ` [RFC PATCH v3] mm/vmpressure: scale window size based on machine memory Benjamin Lee McQueen
2026-03-06 15:52       ` Michal Hocko
2026-03-06 16:44         ` Benjamin Lee McQueen
2026-03-12  7:18           ` Michal Hocko [this message]
2026-03-12  9:50       ` David Hildenbrand (Arm)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=abJo4YQLucQ8zOdM@tiehlicka \
    --to=mhocko@suse.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mcq@disroot.org \
    --cc=rppt@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.