From: Yuan-Hao Hsu <aa9736195201@gmail.com>
To: David Hildenbrand <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Lorenzo Stoakes <ljs@kernel.org>,
liam@infradead.org, Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, Barry Song <baohua@kernel.org>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] mm/memory: reuse the whole exclusive large folio on a write fault
Date: Sat, 19 Sep 2026 19:18:51 +0800 [thread overview]
Message-ID: <20260919111851.678-1-aa9736195201@gmail.com> (raw)
In-Reply-To: <0c0c19d0-997a-4c8d-a103-2b3d153f4e32@kernel.org>
On Sat, 19 Sep 2026 12:10:56 +0200, David Hildenbrand (Arm) wrote:
> Are you measuring the worst-case latency of a single write fault or only the
> average over all writes?
The single fault. Each store is timed by itself (clock_gettime()
before and after), and the latency numbers come from a pattern where
every store takes one of these faults (one store per folio), so there
is nothing else in the average. The tables show the median of those
faults; I also have p99 and max (i7-12700KF, in a VM, us):
v7.3-rc3+ patched
p50 p99 max p50 p99 max
64K, 1 fault 0.42 0.57 25-26 0.71-0.74 0.96-1.10 28-60
2M, 1 fault 0.50 0.67 0.7-1.2 10.0-10.2 12.2-15.8 13-22
max is the slowest store of a run, median over 15 runs. The 25 us on
the base kernel are interrupts; the VM has those on both sides. The
2M row is the worst case by construction, every one of those faults
walks all 512 PTEs.
next prev parent reply other threads:[~2026-09-19 11:18 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 6:42 [PATCH] " Yuan-Hao Hsu
2026-09-18 12:14 ` David Hildenbrand (Arm)
2026-09-18 18:28 ` Yuan-Hao Hsu
2026-09-18 23:48 ` Barry Song
2026-09-19 7:24 ` Yuan-Hao Hsu
2026-09-18 13:54 ` Lorenzo Stoakes (ARM)
2026-09-19 7:31 ` [PATCH v2 0/2] " Yuan-Hao Hsu
2026-09-19 7:31 ` [PATCH v2 1/2] mm/memory: reuse 16 PTEs of an " Yuan-Hao Hsu
2026-09-19 7:31 ` [PATCH v2 2/2] mm/memory: reuse the whole " Yuan-Hao Hsu
2026-09-19 10:10 ` David Hildenbrand (Arm)
2026-09-19 11:18 ` Yuan-Hao Hsu [this message]
2026-09-19 10:08 ` [PATCH v2 0/2] " David Hildenbrand (Arm)
2026-09-19 11:18 ` Yuan-Hao Hsu
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=20260919111851.678-1-aa9736195201@gmail.com \
--to=aa9736195201@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®