All of lore.kernel.org
 help / color / mirror / Atom feed
From: Taha Sezer <tahasezer.is@gmail.com>
To: ljs@kernel.org, akpm@linux-foundation.org
Cc: david@kernel.org, vbabka@kernel.org, mhocko@suse.com,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: vmpressure: scale window size based on machine memory
Date: Mon, 31 Aug 2026 23:43:00 -0700 (PDT)	[thread overview]
Message-ID: <6a9673f4.cbade83c.66f7c.3d66@mx.google.com> (raw)
In-Reply-To: <20260831130316.448-1-tahasezer.is@gmail.com>

Hi Lorenzo, Andrew,

Thanks for the honest and thorough review.

Lorenzo -- yes, I did use an AI coding assistant (Claude) to help
write this patch. I should have included an Assisted-by: tag from
the start and I apologise for the omission. That was a mistake on
my part, not an attempt to hide anything -- I simply was not aware of
the disclosure process for my first submission.

Andrew -- you are absolutely right about the math. The original window
is SWAP_CLUSTER_MAX * 16 = 512 pages, and my formula clamp(fls(mem),
4, 64) produces values well below 16 for every machine under ~8 TB.
The patch shrinks the window on virtually all real hardware, which is
the exact opposite of what the commit message promises. Embarrassing,
and I should have caught this before sending.

For a bit of context on why I chose mm/: I have been writing a hobby
kernel from scratch (Caelum) that includes a VMM with COW and demand
paging, a slab allocator with NUMA-aware allocation, TLB shootdown
via IPI, and SMP boot -- so memory management is the area I am most
comfortable with. That said, comfortable with the concepts clearly
did not save me from a basic arithmetic mistake here, and I take full
responsibility for not verifying the output carefully enough.

Before I send a v2, I would appreciate any guidance:

  1. Is the general idea still worth pursuing -- scaling the window
     logarithmically with total RAM using fls(), or do you think
     the fixed 512-page window is fine as-is and this TODO is
     better left alone?

  2. If the approach is worth fixing: would keeping the original
     multiplier of 16 as the floor (so the window only ever grows
     beyond 512 pages) be the right direction, or would you prefer
     a different scaling strategy entirely?

  3. Any other advice for a first-time contributor on how to
     approach mm/ patches more carefully?

I will hold off on v2 until I hear back, so I do not waste anyone's
time with another half-baked attempt. The next version will include
a proper Assisted-by: Claude:claude-opus-4 tag.

Thanks again for the patience.

Best regards,
Taha Sezer

  parent reply	other threads:[~2026-09-01  6:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-31 13:03 [PATCH] mm: vmpressure: scale window size based on machine memory Taha Sezer
2026-08-31 13:27 ` Lorenzo Stoakes (ARM)
2026-08-31 17:09   ` Andrew Morton
2026-09-01  6:43 ` Taha Sezer [this message]
2026-09-07 13:59   ` 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=6a9673f4.cbade83c.66f7c.3d66@mx.google.com \
    --to=tahasezer.is@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.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.