* Re: (sashiko review) [RFC PATCH v2 3/9] Docs/mm/damon/design: document fail_charge_{num,denom}
From: SeongJae Park @ 2026-04-05 19:34 UTC (permalink / raw)
To: SeongJae Park; +Cc: damon, linux-doc, linux-kernel, linux-mm
In-Reply-To: <20260405151232.102690-4-sj@kernel.org>
TL; DR: sashiko gave me a sounds-good suggestion. I will make a change on the
next revision of this patch.
Forwarding full sashiko review in a reply format with my inline
comments below, for sharing details of my view and doing
followup discussions via mails if needed.
> # review url: https://sashiko.dev/#/patchset/20260405151232.102690-4-sj@kernel.org
> # start of sashiko.dev inline review
> commit c4d090b9bc99178548ec06da52d6f75e0b392a34
> Author: SeongJae Park <sj@kernel.org>
>
> Docs/mm/damon/design: document fail_charge_{num,denom}
>
> Update the DAMON design document to describe the new fail_charge_num and
> fail_charge_denom parameters. These parameters configure the DAMOS action
> failed region quota charge ratio.
>
> > diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
> > index afc7d52bda2f7..8a8b04b5e8537 100644
> > --- a/Documentation/mm/damon/design.rst
> > +++ b/Documentation/mm/damon/design.rst
> > @@ -565,6 +565,27 @@ interface <sysfs_interface>`, refer to :ref:`weights <sysfs_quotas>` part of
> > the documentation.
> >
> >
> > +.. _damon_design_damos_quotas_failed_memory_charging_ratio:
> > +
> > +Action-failed Memory Charging Ratio
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +DAMOS action to a given region can fail for some subsets of the memory of the
> > +region. For example, if the action is ``pageout`` and the region has some
> > +unreclaimable pages, applying the action to the pages will fail. The amount of
> > +system resource that is taken for such failed action applications is usually
> > +different from that for successful action applications. For such cases, users
> > +can set different charging ratio for such failed memory. The ratio can be
> > +specified using ``fail_charge_num`` and ``fail_charge_denom`` parameters. The
> > +two parameters represent the numerator and denominator of the ratio.
>
> Should this documentation include the fallback and default behavior when
> fail_charge_denom is set to 0?
>
> Looking at the core kernel implementation in
> mm/damon/core.c:damos_charge_quota(), the code checks for
> !quota->fail_charge_denom and falls back to charging the entire region size to
> avoid a division-by-zero error.
>
> Additionally, since struct damon_sysfs_quotas is allocated using kzalloc(),
> fail_charge_denom is 0 by default. Would it be helpful to explain this default
> 0 state and the resulting fallback behavior here?
Good suggestion, I will add that.
>
> > +
> > +For example, let's suppose a DAMOS action is applied to a region of 1,000 MiB
> > +size. The action is successfully applied to only 700 MiB of the region.
> > +``fail_charge_num`` and ``fail_charge_denom`` are set to ``1`` and ``1024``,
> > +respectively. Then only 700 MiB and 300 KiB of size (``700 MiB + 300 MiB * 1 /
> > +1024``) will be charged.
> > +
>
> [ ... ]
>
>
> # end of sashiko.dev inline review
> # review url: https://sashiko.dev/#/patchset/20260405151232.102690-4-sj@kernel.org
Thanks,
SJ
# hkml [1] generated a draft of this mail. You can regenerate
# this using below command:
#
# hkml patch sashiko_dev --for_forwarding \
# 20260405151232.102690-4-sj@kernel.org
#
# [1] https://github.com/sjp38/hackermail
^ permalink raw reply
* Re: [PATCH 20/33] rust: kbuild: remove unneeded old `allow`s for generated layout tests
From: Miguel Ojeda @ 2026-04-05 19:31 UTC (permalink / raw)
To: Tamir Duberstein
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <177508434460.73816.4231801886718165891.b4-review@b4>
On Thu, Apr 2, 2026 at 1:01 AM Tamir Duberstein <tamird@kernel.org> wrote:
>
> How about ordering this, the previous patch, and the next patch ahead of
> the version bump to avoid the need to mention it here?
That is reasonable, yeah.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 17/33] rust: kbuild: update `bindgen --rust-target` version and replace comment
From: Miguel Ojeda @ 2026-04-05 19:31 UTC (permalink / raw)
To: Tamir Duberstein
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <177508434455.73816.15756486388132647025.b4-review@b4>
On Thu, Apr 2, 2026 at 1:00 AM Tamir Duberstein <tamird@kernel.org> wrote:
>
> Some citations pointing to the upstream changes would be good.
I added a couple links as usual, plus a reference to commit
7a5f93ea5862 ("rust: kbuild: set `bindgen`'s Rust target version")
that has most of the details.
[ The comment already mentioned the version, and the commit that added
that message has the details, but I agree it is a good idea to add
some references. ]
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH 11/33] rust: alloc: simplify with `NonNull::add()` now that it is stable
From: Miguel Ojeda @ 2026-04-05 19:31 UTC (permalink / raw)
To: Tamir Duberstein
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <177508434445.73816.7873322235592463050.b4-review@b4>
On Thu, Apr 2, 2026 at 1:00 AM Tamir Duberstein <tamird@kernel.org> wrote:
>
> This description is inconsistent with the previous one which had
> citations for both the feature (function in this case) and the feature
> in which it became stable (available in this case). I don't prefer
> either style in particular, just that things are consistent.
Sure, I added a couple references. I think it is good to be consistent
(well, at least within a patch series, but I wouldn't say no to more
information even if it is inconsistent sometimes, especially across
different patch series, since everyone writes messages a bit
differently...).
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] docs: use acknowledgment in submitting-patches
From: Krzysztof Kozlowski @ 2026-04-05 19:30 UTC (permalink / raw)
To: CaoRuichuang, corbet; +Cc: skhan, workflows, linux-doc, linux-kernel
In-Reply-To: <20260405183602.73797-1-create0818@163.com>
On 05/04/2026 20:36, CaoRuichuang wrote:
> Signed-off-by: CaoRuichuang <create0818@163.com>
> ---
> Documentation/process/submitting-patches.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index e69d19a..5c44be9 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -486,9 +486,9 @@ reviewed it as thoroughly as if a Reviewed-by: was provided. Similarly, a key
> user may not have carried out a technical review of the patch, yet they may be
> satisfied with the general approach, the feature or the user-facing interface.
>
> -Acked-by: does not necessarily indicate acknowledgement of the entire patch.
> +Acked-by: does not necessarily indicate acknowledgment of the entire patch.
Pointless change. You are replacing one correct spelling with another
correct one. And your commit msg is empty...
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 10/33] rust: transmute: simplify code with Rust 1.80.0 `split_at_*checked()`
From: Miguel Ojeda @ 2026-04-05 19:29 UTC (permalink / raw)
To: Tamir Duberstein
Cc: Miguel Ojeda, Nathan Chancellor, Nicolas Schier, Danilo Krummrich,
Andreas Hindborg, Catalin Marinas, Will Deacon, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Courbot, David Airlie,
Simona Vetter, Brendan Higgins, David Gow, Greg Kroah-Hartman,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas, Alice Ryhl, Jonathan Corbet, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Trevor Gross, rust-for-linux,
linux-kbuild, Lorenzo Stoakes, Vlastimil Babka, Liam R . Howlett,
Uladzislau Rezki, linux-block, linux-arm-kernel, Alexandre Ghiti,
linux-riscv, nouveau, dri-devel, Rae Moar, linux-kselftest,
kunit-dev, Nick Desaulniers, Bill Wendling, Justin Stitt, llvm,
linux-kernel, Shuah Khan, linux-doc
In-Reply-To: <177508434443.73816.5437391869400189147.b4-review@b4>
On Thu, Apr 2, 2026 at 1:00 AM Tamir Duberstein <tamird@kernel.org> wrote:
>
> "beyond" is probably not the right word here?
I think you are right -- reworded.
Thanks!
Cheers,
Miguel
^ permalink raw reply
* [PATCH v6 1/1] mm/damon: add node_eligible_mem_bp and node_ineligible_mem_bp goal metrics
From: Ravi Jonnalagadda @ 2026-04-05 18:42 UTC (permalink / raw)
To: sj, damon, linux-mm, linux-kernel, linux-doc
Cc: akpm, corbet, bijan311, ajayjoshi, honggyu.kim, yunjeong.mun,
ravis.opensrc
In-Reply-To: <20260405184247.2690-1-ravis.opensrc@gmail.com>
Add new quota goal metrics for memory tiering that track scheme-eligible
memory distribution across NUMA nodes:
- DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP: ratio of eligible memory on a node
- DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP: ratio of ineligible memory on a
node
These complementary metrics enable push-pull migration schemes that
maintain a target memory distribution across different NUMA nodes
representing different memory tiers, based on access patterns defined
by each scheme.
The metrics iterate scheme-eligible regions and use damon_get_folio()
to determine NUMA node placement of each folio, calculating the ratio
of eligible memory on the specified node versus total eligible memory.
The implementation is guarded by CONFIG_DAMON_PADDR since damon_get_folio()
is only available when physical address space monitoring is enabled.
Suggested-by: SeongJae Park <sj@kernel.org>
Signed-off-by: Ravi Jonnalagadda <ravis.opensrc@gmail.com>
---
include/linux/damon.h | 6 ++
mm/damon/core.c | 188 ++++++++++++++++++++++++++++++++++++---
mm/damon/sysfs-schemes.c | 12 +++
3 files changed, 192 insertions(+), 14 deletions(-)
diff --git a/include/linux/damon.h b/include/linux/damon.h
index f2cdb7c3f5e6..a268f44beabf 100644
--- a/include/linux/damon.h
+++ b/include/linux/damon.h
@@ -159,6 +159,10 @@ enum damos_action {
* @DAMOS_QUOTA_NODE_MEMCG_FREE_BP: MemFree ratio of a node for a cgroup.
* @DAMOS_QUOTA_ACTIVE_MEM_BP: Active to total LRU memory ratio.
* @DAMOS_QUOTA_INACTIVE_MEM_BP: Inactive to total LRU memory ratio.
+ * @DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP: Scheme-eligible memory ratio of a
+ * node.
+ * @DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP: Scheme-ineligible memory ratio of a
+ * node.
* @NR_DAMOS_QUOTA_GOAL_METRICS: Number of DAMOS quota goal metrics.
*
* Metrics equal to larger than @NR_DAMOS_QUOTA_GOAL_METRICS are unsupported.
@@ -172,6 +176,8 @@ enum damos_quota_goal_metric {
DAMOS_QUOTA_NODE_MEMCG_FREE_BP,
DAMOS_QUOTA_ACTIVE_MEM_BP,
DAMOS_QUOTA_INACTIVE_MEM_BP,
+ DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
+ DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP,
NR_DAMOS_QUOTA_GOAL_METRICS,
};
diff --git a/mm/damon/core.c b/mm/damon/core.c
index 3bc7a2bbfe7d..bac810f740c3 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -17,6 +17,9 @@
#include <linux/string.h>
#include <linux/string_choices.h>
+/* for damon_get_folio() used by node eligible memory metrics */
+#include "ops-common.h"
+
#define CREATE_TRACE_POINTS
#include <trace/events/damon.h>
@@ -2282,7 +2285,136 @@ static unsigned long damos_get_node_memcg_used_bp(
numerator = i.totalram - used_pages;
return mult_frac(numerator, 10000, i.totalram);
}
-#else
+
+#ifdef CONFIG_DAMON_PADDR
+/*
+ * damos_calc_eligible_bytes() - Calculate raw eligible bytes per node.
+ * @c: The DAMON context.
+ * @s: The scheme.
+ * @nid: The target NUMA node id.
+ * @total: Output for total eligible bytes across all nodes.
+ *
+ * Iterates through each folio in eligible regions to accurately determine
+ * which node the memory resides on. Returns eligible bytes on the specified
+ * node and sets *total to the sum across all nodes.
+ *
+ * Note: This function requires damon_get_folio() from ops-common.c, which is
+ * only available when CONFIG_DAMON_PADDR or CONFIG_DAMON_VADDR is enabled.
+ */
+static unsigned long damos_calc_eligible_bytes(struct damon_ctx *c,
+ struct damos *s, int nid, unsigned long *total)
+{
+ struct damon_target *t;
+ struct damon_region *r;
+ unsigned long total_eligible = 0;
+ unsigned long node_eligible = 0;
+
+ damon_for_each_target(t, c) {
+ damon_for_each_region(r, t) {
+ phys_addr_t addr, end_addr;
+
+ if (!__damos_valid_target(r, s))
+ continue;
+
+ /* Convert from core address units to physical bytes */
+ addr = r->ar.start * c->addr_unit;
+ end_addr = r->ar.end * c->addr_unit;
+ while (addr < end_addr) {
+ struct folio *folio;
+ unsigned long folio_sz, counted;
+
+ folio = damon_get_folio(PHYS_PFN(addr));
+ if (!folio) {
+ addr += PAGE_SIZE;
+ continue;
+ }
+
+ folio_sz = folio_size(folio);
+ /*
+ * Clip to region boundaries to avoid counting
+ * bytes outside the region when folio spans
+ * region boundaries.
+ */
+ counted = min(folio_sz, (unsigned long)(end_addr - addr));
+ total_eligible += counted;
+ if (folio_nid(folio) == nid)
+ node_eligible += counted;
+
+ addr += folio_sz;
+ folio_put(folio);
+ }
+ }
+ }
+
+ *total = total_eligible;
+ return node_eligible;
+}
+
+/*
+ * damos_get_node_eligible_mem_bp() - Get eligible memory ratio for a node.
+ * @c: The DAMON context.
+ * @s: The scheme.
+ * @nid: The target NUMA node id.
+ *
+ * Calculates scheme-eligible bytes on the specified node and returns the
+ * ratio in basis points (0-10000) relative to total eligible bytes across
+ * all nodes.
+ */
+static unsigned long damos_get_node_eligible_mem_bp(struct damon_ctx *c,
+ struct damos *s, int nid)
+{
+ unsigned long total_eligible = 0;
+ unsigned long node_eligible = 0;
+
+ if (nid < 0 || nid >= MAX_NUMNODES || !node_online(nid))
+ return 0;
+
+ node_eligible = damos_calc_eligible_bytes(c, s, nid, &total_eligible);
+
+ if (!total_eligible)
+ return 0;
+
+ return mult_frac(node_eligible, 10000, total_eligible);
+}
+
+static unsigned long damos_get_node_ineligible_mem_bp(struct damon_ctx *c,
+ struct damos *s, int nid)
+{
+ unsigned long total_eligible = 0;
+ unsigned long node_eligible;
+
+ if (nid < 0 || nid >= MAX_NUMNODES || !node_online(nid))
+ return 0;
+
+ node_eligible = damos_calc_eligible_bytes(c, s, nid, &total_eligible);
+
+ /* No eligible memory anywhere - ratio is undefined, return 0 */
+ if (!total_eligible)
+ return 0;
+
+ /* Compute ineligible ratio directly: 10000 - eligible_bp */
+ return 10000 - mult_frac(node_eligible, 10000, total_eligible);
+}
+#else /* CONFIG_DAMON_PADDR */
+/*
+ * Stub functions when CONFIG_DAMON_PADDR is disabled.
+ * The node_eligible/ineligible metrics require physical address operations
+ * to iterate folios, which are only available with PA-mode DAMON.
+ */
+static unsigned long damos_get_node_eligible_mem_bp(struct damon_ctx *c,
+ struct damos *s, int nid)
+{
+ return 0;
+}
+
+static unsigned long damos_get_node_ineligible_mem_bp(struct damon_ctx *c,
+ struct damos *s, int nid)
+{
+ return 0;
+}
+#endif /* CONFIG_DAMON_PADDR */
+
+#else /* CONFIG_NUMA */
static __kernel_ulong_t damos_get_node_mem_bp(
struct damos_quota_goal *goal)
{
@@ -2294,7 +2426,19 @@ static unsigned long damos_get_node_memcg_used_bp(
{
return 0;
}
-#endif
+
+static unsigned long damos_get_node_eligible_mem_bp(struct damon_ctx *c,
+ struct damos *s, int nid)
+{
+ return 0;
+}
+
+static unsigned long damos_get_node_ineligible_mem_bp(struct damon_ctx *c,
+ struct damos *s, int nid)
+{
+ return 0;
+}
+#endif /* CONFIG_NUMA */
/*
* Returns LRU-active or inactive memory to total LRU memory size ratio.
@@ -2314,7 +2458,8 @@ static unsigned int damos_get_in_active_mem_bp(bool active_ratio)
return mult_frac(inactive, 10000, total);
}
-static void damos_set_quota_goal_current_value(struct damos_quota_goal *goal)
+static void damos_set_quota_goal_current_value(struct damon_ctx *c,
+ struct damos *s, struct damos_quota_goal *goal)
{
u64 now_psi_total;
@@ -2340,19 +2485,28 @@ static void damos_set_quota_goal_current_value(struct damos_quota_goal *goal)
goal->current_value = damos_get_in_active_mem_bp(
goal->metric == DAMOS_QUOTA_ACTIVE_MEM_BP);
break;
+ case DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP:
+ goal->current_value = damos_get_node_eligible_mem_bp(c, s,
+ goal->nid);
+ break;
+ case DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP:
+ goal->current_value = damos_get_node_ineligible_mem_bp(c, s,
+ goal->nid);
+ break;
default:
break;
}
}
/* Return the highest score since it makes schemes least aggressive */
-static unsigned long damos_quota_score(struct damos_quota *quota)
+static unsigned long damos_quota_score(struct damon_ctx *c, struct damos *s)
{
+ struct damos_quota *quota = &s->quota;
struct damos_quota_goal *goal;
unsigned long highest_score = 0;
damos_for_each_quota_goal(goal, quota) {
- damos_set_quota_goal_current_value(goal);
+ damos_set_quota_goal_current_value(c, s, goal);
highest_score = max(highest_score,
mult_frac(goal->current_value, 10000,
goal->target_value));
@@ -2361,17 +2515,20 @@ static unsigned long damos_quota_score(struct damos_quota *quota)
return highest_score;
}
-static void damos_goal_tune_esz_bp_consist(struct damos_quota *quota)
+static void damos_goal_tune_esz_bp_consist(struct damon_ctx *c, struct damos *s)
{
- unsigned long score = damos_quota_score(quota);
+ struct damos_quota *quota = &s->quota;
+ unsigned long score = damos_quota_score(c, s);
quota->esz_bp = damon_feed_loop_next_input(
max(quota->esz_bp, 10000UL), score);
}
-static void damos_goal_tune_esz_bp_temporal(struct damos_quota *quota)
+static void damos_goal_tune_esz_bp_temporal(struct damon_ctx *c,
+ struct damos *s)
{
- unsigned long score = damos_quota_score(quota);
+ struct damos_quota *quota = &s->quota;
+ unsigned long score = damos_quota_score(c, s);
if (score >= 10000)
quota->esz_bp = 0;
@@ -2384,8 +2541,9 @@ static void damos_goal_tune_esz_bp_temporal(struct damos_quota *quota)
/*
* Called only if quota->ms, or quota->sz are set, or quota->goals is not empty
*/
-static void damos_set_effective_quota(struct damos_quota *quota)
+static void damos_set_effective_quota(struct damon_ctx *c, struct damos *s)
{
+ struct damos_quota *quota = &s->quota;
unsigned long throughput;
unsigned long esz = ULONG_MAX;
@@ -2396,9 +2554,9 @@ static void damos_set_effective_quota(struct damos_quota *quota)
if (!list_empty("a->goals)) {
if (quota->goal_tuner == DAMOS_QUOTA_GOAL_TUNER_CONSIST)
- damos_goal_tune_esz_bp_consist(quota);
+ damos_goal_tune_esz_bp_consist(c, s);
else if (quota->goal_tuner == DAMOS_QUOTA_GOAL_TUNER_TEMPORAL)
- damos_goal_tune_esz_bp_temporal(quota);
+ damos_goal_tune_esz_bp_temporal(c, s);
esz = quota->esz_bp / 10000;
}
@@ -2445,7 +2603,9 @@ static void damos_adjust_quota(struct damon_ctx *c, struct damos *s)
/* First charge window */
if (!quota->total_charged_sz && !quota->charged_from) {
quota->charged_from = jiffies;
- damos_set_effective_quota(quota);
+ damos_set_effective_quota(c, s);
+ if (trace_damos_esz_enabled())
+ damos_trace_esz(c, s, quota);
}
/* New charge window starts */
@@ -2460,7 +2620,7 @@ static void damos_adjust_quota(struct damon_ctx *c, struct damos *s)
quota->charged_sz = 0;
if (trace_damos_esz_enabled())
cached_esz = quota->esz;
- damos_set_effective_quota(quota);
+ damos_set_effective_quota(c, s);
if (trace_damos_esz_enabled() && quota->esz != cached_esz)
damos_trace_esz(c, s, quota);
}
diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
index 5186966dafb3..aade681b4868 100644
--- a/mm/damon/sysfs-schemes.c
+++ b/mm/damon/sysfs-schemes.c
@@ -1084,6 +1084,14 @@ struct damos_sysfs_qgoal_metric_name damos_sysfs_qgoal_metric_names[] = {
.metric = DAMOS_QUOTA_INACTIVE_MEM_BP,
.name = "inactive_mem_bp",
},
+ {
+ .metric = DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP,
+ .name = "node_eligible_mem_bp",
+ },
+ {
+ .metric = DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP,
+ .name = "node_ineligible_mem_bp",
+ },
};
static ssize_t target_metric_show(struct kobject *kobj,
@@ -2655,6 +2663,10 @@ static int damos_sysfs_add_quota_score(
case DAMOS_QUOTA_NODE_MEM_FREE_BP:
goal->nid = sysfs_goal->nid;
break;
+ case DAMOS_QUOTA_NODE_ELIGIBLE_MEM_BP:
+ case DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP:
+ goal->nid = sysfs_goal->nid;
+ break;
case DAMOS_QUOTA_NODE_MEMCG_USED_BP:
case DAMOS_QUOTA_NODE_MEMCG_FREE_BP:
err = damon_sysfs_memcg_path_to_id(
--
2.43.0
^ permalink raw reply related
* [PATCH v6 0/1] mm/damon: add node_eligible_mem_bp and node_ineligible_mem_bp goal metrics
From: Ravi Jonnalagadda @ 2026-04-05 18:42 UTC (permalink / raw)
To: sj, damon, linux-mm, linux-kernel, linux-doc
Cc: akpm, corbet, bijan311, ajayjoshi, honggyu.kim, yunjeong.mun,
ravis.opensrc
Changes since v5:
=================
https://lore.kernel.org/linux-mm/20260404012215.1539-1-ravis.opensrc@gmail.com/
- Rebased onto mm-new instead of damon/next for sashiko review
- Removed Reported-by/Closes tags per maintainer feedback (not needed
for bugs found before merge)
Changes since v4:
=================
https://lore.kernel.org/linux-mm/20260320190453.1430-1-ravis.opensrc@gmail.com/
- Fixed commit message description for DAMOS_QUOTA_NODE_INELIGIBLE_MEM_BP
per review feedback
- Added clarifying comment for ops-common.h include (for damon_get_folio())
- Fixed build error when CONFIG_DAMON_PADDR is disabled by adding
#ifdef CONFIG_DAMON_PADDR guards around functions using damon_get_folio()
- Dropped RFC tag per maintainer feedback
This patch is based on top of mm-new.
Background and Motivation
=========================
In heterogeneous memory systems, controlling memory distribution across
NUMA nodes is essential for performance optimization. This patch enables
system-wide page distribution with target-state goals such as "maintain
30% of scheme-eligible memory on CXL" using PA-mode DAMON schemes.
What These Metrics Measure
==========================
node_eligible_mem_bp:
scheme_eligible_bytes_on_node / total_scheme_eligible_bytes * 10000
node_ineligible_mem_bp:
(total - scheme_eligible_bytes_on_node) / total * 10000
These metrics are complementary: eligible_bp + ineligible_bp = 10000 bp.
Two-Scheme Setup for Hot Page Distribution
==========================================
For maintaining hot memory on DRAM (node 0) and CXL (node 1) in a 7:3
ratio:
PUSH scheme: migrate_hot from node 0 -> node 1
goal: node_ineligible_mem_bp, nid=0, target=3000
"Move hot pages from DRAM to CXL if more than 70% of hot data is
in DRAM"
PULL scheme: migrate_hot from node 1 -> node 0
goal: node_eligible_mem_bp, nid=0, target=7000
"Move hot pages from CXL to DRAM if less than 70% of hot data is
in DRAM"
The complementary goals create a feedback loop that converges to the
target distribution.
Testing Results
===============
Functionally tested on a two-node heterogeneous memory system with DRAM
(node 0) and CXL memory (node 1). A PUSH+PULL scheme configuration using
migrate_hot actions was used to reach a target hot memory ratio between
the two tiers. Testing used the TEMPORAL goal tuner available in
damon/next and mm-unstable.
With the TEMPORAL tuner, the system converges quickly to the target
distribution. The tuner drives esz to maximum when under goal and to
zero once the goal is met, forming a simple on/off feedback loop that
stabilizes at the desired ratio.
With the CONSIST tuner, the scheme still converges but more slowly, as
it migrates and then throttles itself based on quota feedback. The time
to reach the goal varies depending on workload intensity.
Note: These metrics work with both TEMPORAL and CONSIST goal tuners.
Ravi Jonnalagadda (1):
mm/damon: add node_eligible_mem_bp and node_ineligible_mem_bp goal
metrics
include/linux/damon.h | 6 ++
mm/damon/core.c | 188 ++++++++++++++++++++++++++++++++++++---
mm/damon/sysfs-schemes.c | 12 +++
3 files changed, 192 insertions(+), 14 deletions(-)
base-commit: b47b4fa4c232ee36aae58630e9d6520e35d33f3a
--
2.43.0
^ permalink raw reply
* [PATCH] docs: use acknowledgment in submitting-patches
From: CaoRuichuang @ 2026-04-05 18:36 UTC (permalink / raw)
To: corbet; +Cc: skhan, workflows, linux-doc, linux-kernel, CaoRuichuang
Signed-off-by: CaoRuichuang <create0818@163.com>
---
Documentation/process/submitting-patches.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index e69d19a..5c44be9 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -486,9 +486,9 @@ reviewed it as thoroughly as if a Reviewed-by: was provided. Similarly, a key
user may not have carried out a technical review of the patch, yet they may be
satisfied with the general approach, the feature or the user-facing interface.
-Acked-by: does not necessarily indicate acknowledgement of the entire patch.
+Acked-by: does not necessarily indicate acknowledgment of the entire patch.
For example, if a patch affects multiple subsystems and has an Acked-by: from
-one subsystem maintainer then this usually indicates acknowledgement of just
+one subsystem maintainer then this usually indicates acknowledgment of just
the part which affects that maintainer's code. Judgement should be used here.
When in doubt people should refer to the original discussion in the mailing
list archives. A "# Suffix" may also be used in this case to clarify.
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* Re: [PATCH v3 02/24] PCI: Add API to track PCI devices preserved across Live Update
From: Zhu Yanjun @ 2026-04-05 16:56 UTC (permalink / raw)
To: David Matlack, yanjun.zhu@linux.dev
Cc: Alex Williamson, Bjorn Helgaas, Adithya Jayachandran,
Alexander Graf, Alex Mastro, Andrew Morton, Ankit Agrawal,
Arnd Bergmann, Askar Safin, Borislav Petkov (AMD), Chris Li,
Dapeng Mi, David Rientjes, Feng Tang, Jacob Pan, Jason Gunthorpe,
Jason Gunthorpe, Jonathan Corbet, Josh Hilke, Kees Cook,
Kevin Tian, kexec, kvm, Leon Romanovsky, Leon Romanovsky,
linux-doc, linux-kernel, linux-kselftest, linux-mm, linux-pci,
Li RongQing, Lukas Wunner, Marco Elver, Michał Winiarski,
Mike Rapoport, Parav Pandit, Pasha Tatashin, Paul E. McKenney,
Pawan Gupta, Peter Zijlstra (Intel), Pranjal Shrivastava,
Pratyush Yadav, Raghavendra Rao Ananta, Randy Dunlap,
Rodrigo Vivi, Saeed Mahameed, Samiullah Khawaja, Shuah Khan,
Vipin Sharma, Vivek Kasireddy, William Tu, Yi Liu
In-Reply-To: <CALzav=eyf4XRTi8MfE_GBNSm+tjmfX7=d0M8Aj5Hh0vJn7huew@mail.gmail.com>
在 2026/4/3 14:58, David Matlack 写道:
> On Thu, Apr 2, 2026 at 2:29 PM Yanjun.Zhu <yanjun.zhu@linux.dev> wrote:
>> On 3/23/26 4:57 PM, David Matlack wrote:
>>> +config PCI_LIVEUPDATE
>>> + bool "PCI Live Update Support (EXPERIMENTAL)"
>>> + depends on PCI && LIVEUPDATE
>>> + help
>>> + Support for preserving PCI devices across a Live Update. This option
>>> + should only be enabled by developers working on implementing this
>>> + support. Once enough support as landed in the kernel, this option
>>> + will no longer be marked EXPERIMENTAL.
>>> +
>>> + If unsure, say N.
>> Currently, it only supports 'n' or 'y'. Is it possible to add 'm'
>> (modular support)?
>>
>> This would allow the feature to be built as a kernel module. For
>> development
>>
>> purposes, modularization means we only need to recompile a single module
>>
>> for testing, rather than rebuilding the entire kernel. Compiling a
>> module should
>>
>> be significantly faster than a full kernel build.
> I don't think it is possible for CONFIG_PCI_LIVEUPDATE to support 'm'.
> pci_setup_device() (which is under CONFIG_PCI) needs to call
> pci_liveupdate_setup_device(), and CONFIG_PCI cannot be built as a
> module. This call is necessary so the PCI core knows whether a device
> being enumerated was preserved across a previous Live Update.
After the following changes, the liveupdate.ko can be generated
successfully.
"
# ls drivers/pci/liveupdate.ko
drivers/pci/liveupdate.ko
"
diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 05307d89c3f4..e172c31b33fa 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -335,7 +335,7 @@ config VGA_ARB_MAX_GPUS
multiple GPUS. The overhead for each GPU is very small.
config PCI_LIVEUPDATE
- bool "PCI Live Update Support (EXPERIMENTAL)"
+ tristate "PCI Live Update Support (EXPERIMENTAL)"
depends on PCI && LIVEUPDATE
help
Support for preserving PCI devices across a Live Update. This
option
diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
index c1251f4f8438..71bab8ecba85 100644
--- a/drivers/pci/liveupdate.c
+++ b/drivers/pci/liveupdate.c
@@ -413,3 +413,26 @@ void pci_liveupdate_unregister_flb(struct
liveupdate_file_handler *fh)
liveupdate_unregister_flb(fh, &pci_liveupdate_flb);
}
EXPORT_SYMBOL_GPL(pci_liveupdate_unregister_flb);
+
+extern void (*pci_liveupdate_setup_device_hook)(struct pci_dev *dev);
+extern u32 (*pci_liveupdate_incoming_nr_devices_hook)(void);
+static int __init liveupdate_module_init(void)
+{
+ pci_liveupdate_setup_device_hook = pci_liveupdate_setup_device;
+ pci_liveupdate_incoming_nr_devices_hook =
pci_liveupdate_incoming_nr_devices;
+ pr_info("loaded\n");
+ return 0;
+}
+
+static void __exit liveupdate_module_exit(void)
+{
+ pci_liveupdate_setup_device_hook = NULL;
+ pci_liveupdate_incoming_nr_devices_hook = NULL;
+ pr_info("unloaded\n");
+}
+
+module_init(liveupdate_module_init);
+module_exit(liveupdate_module_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("PCI Live Update Support");
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index 979cb9921340..93f76500cb0d 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -1434,18 +1434,12 @@ static inline int pci_msix_write_tph_tag(struct
pci_dev *pdev, unsigned int inde
(PCI_CONF1_ADDRESS(bus, dev, func, reg) | \
PCI_CONF1_EXT_REG(reg))
-#ifdef CONFIG_PCI_LIVEUPDATE
+#if IS_ENABLED(CONFIG_PCI_LIVEUPDATE)
void pci_liveupdate_setup_device(struct pci_dev *dev);
-u32 pci_liveupdate_incoming_nr_devices(void);
#else
static inline void pci_liveupdate_setup_device(struct pci_dev *dev)
{
}
-
-static inline u32 pci_liveupdate_incoming_nr_devices(void)
-{
- return 0;
-}
#endif
#endif /* DRIVERS_PCI_H */
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 165056d71e66..4880302bca43 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1369,6 +1369,9 @@ bool pci_ea_fixed_busnrs(struct pci_dev *dev, u8
*sec, u8 *sub)
return true;
}
+u32 (*pci_liveupdate_incoming_nr_devices_hook)(void) = NULL;
+EXPORT_SYMBOL_GPL(pci_liveupdate_incoming_nr_devices_hook);
+
static bool pci_assign_all_busses(void)
{
if (!pcibios_assign_all_busses())
@@ -1389,7 +1392,7 @@ static bool pci_assign_all_busses(void)
* numbers during the initial cold boot, and then that topology
would
* then remain fixed across any subsequent Live Updates.
*/
- if (pci_liveupdate_incoming_nr_devices()) {
+ if (pci_liveupdate_incoming_nr_devices_hook &&
pci_liveupdate_incoming_nr_devices_hook()) {
pr_info_once("Ignoring pci=assign-busses and inheriting
bus numbers during Live Update\n");
return false;
}
@@ -2030,6 +2033,9 @@ static const char *pci_type_str(struct pci_dev *dev)
}
}
+void (*pci_liveupdate_setup_device_hook)(struct pci_dev *dev) = NULL;
+EXPORT_SYMBOL_GPL(pci_liveupdate_setup_device_hook);
+
/**
* pci_setup_device - Fill in class and map information of a device
* @dev: the device structure to fill
@@ -2091,7 +2097,8 @@ int pci_setup_device(struct pci_dev *dev)
if (pci_early_dump)
early_dump_pci_device(dev);
- pci_liveupdate_setup_device(dev);
+ if (pci_liveupdate_setup_device_hook)
+ pci_liveupdate_setup_device_hook(dev);
/* Need to have dev->class ready */
dev->cfg_size = pci_cfg_space_size(dev);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 27ee9846a2fd..aaab6adb487e 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -592,7 +592,7 @@ struct pci_dev {
u8 tph_mode; /* TPH mode */
u8 tph_req_type; /* TPH requester type */
#endif
-#ifdef CONFIG_PCI_LIVEUPDATE
+#if IS_ENABLED(CONFIG_PCI_LIVEUPDATE)
unsigned int liveupdate_incoming:1; /* Preserved by
previous kernel */
unsigned int liveupdate_outgoing:1; /* Preserved for next
kernel */
#endif
@@ -2876,7 +2876,7 @@ void pci_uevent_ers(struct pci_dev *pdev, enum
pci_ers_result err_type);
WARN_ONCE(condition, "%s %s: " fmt, \
dev_driver_string(&(pdev)->dev), pci_name(pdev), ##arg)
-#ifdef CONFIG_PCI_LIVEUPDATE
+#if IS_ENABLED(CONFIG_PCI_LIVEUPDATE)
int pci_liveupdate_preserve(struct pci_dev *dev);
void pci_liveupdate_unpreserve(struct pci_dev *dev);
int pci_liveupdate_retrieve(struct pci_dev *dev);
diff --git a/kernel/liveupdate/luo_flb.c b/kernel/liveupdate/luo_flb.c
index 874830f8e44d..33fbdc6c417c 100644
--- a/kernel/liveupdate/luo_flb.c
+++ b/kernel/liveupdate/luo_flb.c
@@ -461,7 +461,7 @@ int liveupdate_register_flb(struct
liveupdate_file_handler *fh,
return 0;
}
-
+EXPORT_SYMBOL_GPL(liveupdate_register_flb);
/**
* liveupdate_unregister_flb - Remove an FLB dependency from a file
handler.
* @fh: The file handler that is currently depending on the FLB.
@@ -487,7 +487,7 @@ void liveupdate_unregister_flb(struct
liveupdate_file_handler *fh,
luo_flb_unregister_one(fh, flb);
}
-
+EXPORT_SYMBOL_GPL(liveupdate_unregister_flb);
/**
* liveupdate_flb_get_incoming - Retrieve the incoming FLB object.
* @flb: The FLB definition.
@@ -525,7 +525,7 @@ int liveupdate_flb_get_incoming(struct
liveupdate_flb *flb, void **objp)
return 0;
}
-
+EXPORT_SYMBOL_GPL(liveupdate_flb_get_incoming);
/**
* liveupdate_flb_get_outgoing - Retrieve the outgoing FLB object.
* @flb: The FLB definition.
@@ -552,6 +552,7 @@ int liveupdate_flb_get_outgoing(struct
liveupdate_flb *flb, void **objp)
return 0;
}
+EXPORT_SYMBOL_GPL(liveupdate_flb_get_outgoing);
int __init luo_flb_setup_outgoing(void *fdt_out)
{
--
Best Regards,
Yanjun.Zhu
^ permalink raw reply related
* [PATCH v1] Documentation/rtla: Convert links to RST format
From: Costa Shulyupin @ 2026-04-05 16:38 UTC (permalink / raw)
To: Steven Rostedt, Tomas Glozar, Jonathan Corbet, Shuah Khan,
linux-trace-kernel, linux-kernel, linux-doc
Cc: Costa Shulyupin
Web links in the documentation are not properly displayed.
In the man pages web links look like:
Osnoise tracer documentation: < <https://www.kernel.org/doc/html/lat‐
est/trace/osnoise-tracer.html> >
On web pages the URL caption is the URL itself.
Convert tracer documentation links to RST anonymous hyperlink format
for better rendering. Use newer docs.kernel.org instead of
www.kernel.org/doc/html/latest for brevity.
After the change, the links in the man pages look like:
Osnoise tracer <https://docs.kernel.org/trace/osnoise-tracer.html>
On web pages the captions are the titles of the links.
Signed-off-by: Costa Shulyupin <costa.shul@redhat.com>
---
Documentation/tools/rtla/rtla-hwnoise.rst | 2 +-
Documentation/tools/rtla/rtla-osnoise-hist.rst | 2 +-
Documentation/tools/rtla/rtla-osnoise-top.rst | 2 +-
Documentation/tools/rtla/rtla-osnoise.rst | 2 +-
Documentation/tools/rtla/rtla-timerlat-hist.rst | 2 +-
Documentation/tools/rtla/rtla-timerlat-top.rst | 2 +-
Documentation/tools/rtla/rtla-timerlat.rst | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/tools/rtla/rtla-hwnoise.rst b/Documentation/tools/rtla/rtla-hwnoise.rst
index 26512b15fe7b..5930bbca4522 100644
--- a/Documentation/tools/rtla/rtla-hwnoise.rst
+++ b/Documentation/tools/rtla/rtla-hwnoise.rst
@@ -100,7 +100,7 @@ SEE ALSO
**rtla-osnoise**\(1)
-Osnoise tracer documentation: <https://www.kernel.org/doc/html/latest/trace/osnoise-tracer.html>
+`Osnoise tracer <https://docs.kernel.org/trace/osnoise-tracer.html>`__
AUTHOR
======
diff --git a/Documentation/tools/rtla/rtla-osnoise-hist.rst b/Documentation/tools/rtla/rtla-osnoise-hist.rst
index 007521c865d9..6ddea2c6d490 100644
--- a/Documentation/tools/rtla/rtla-osnoise-hist.rst
+++ b/Documentation/tools/rtla/rtla-osnoise-hist.rst
@@ -59,7 +59,7 @@ SEE ALSO
========
**rtla-osnoise**\(1), **rtla-osnoise-top**\(1)
-*osnoise* tracer documentation: <https://www.kernel.org/doc/html/latest/trace/osnoise-tracer.html>
+`Osnoise tracer <https://docs.kernel.org/trace/osnoise-tracer.html>`__
AUTHOR
======
diff --git a/Documentation/tools/rtla/rtla-osnoise-top.rst b/Documentation/tools/rtla/rtla-osnoise-top.rst
index 6ccadae38945..b91c02ac2bbe 100644
--- a/Documentation/tools/rtla/rtla-osnoise-top.rst
+++ b/Documentation/tools/rtla/rtla-osnoise-top.rst
@@ -54,7 +54,7 @@ SEE ALSO
**rtla-osnoise**\(1), **rtla-osnoise-hist**\(1)
-Osnoise tracer documentation: <https://www.kernel.org/doc/html/latest/trace/osnoise-tracer.html>
+`Osnoise tracer <https://docs.kernel.org/trace/osnoise-tracer.html>`__
AUTHOR
======
diff --git a/Documentation/tools/rtla/rtla-osnoise.rst b/Documentation/tools/rtla/rtla-osnoise.rst
index 540d2bf6c152..decd9e11fcf2 100644
--- a/Documentation/tools/rtla/rtla-osnoise.rst
+++ b/Documentation/tools/rtla/rtla-osnoise.rst
@@ -50,7 +50,7 @@ SEE ALSO
========
**rtla-osnoise-top**\(1), **rtla-osnoise-hist**\(1)
-Osnoise tracer documentation: <https://www.kernel.org/doc/html/latest/trace/osnoise-tracer.html>
+`Osnoise tracer <https://docs.kernel.org/trace/osnoise-tracer.html>`__
AUTHOR
======
diff --git a/Documentation/tools/rtla/rtla-timerlat-hist.rst b/Documentation/tools/rtla/rtla-timerlat-hist.rst
index f56fe546411b..dab75677b06e 100644
--- a/Documentation/tools/rtla/rtla-timerlat-hist.rst
+++ b/Documentation/tools/rtla/rtla-timerlat-hist.rst
@@ -104,7 +104,7 @@ SEE ALSO
========
**rtla-timerlat**\(1), **rtla-timerlat-top**\(1)
-*timerlat* tracer documentation: <https://www.kernel.org/doc/html/latest/trace/timerlat-tracer.html>
+`Timerlat tracer <https://docs.kernel.org/trace/timerlat-tracer.html>`__
AUTHOR
======
diff --git a/Documentation/tools/rtla/rtla-timerlat-top.rst b/Documentation/tools/rtla/rtla-timerlat-top.rst
index 72d85e36c193..05959f1a4661 100644
--- a/Documentation/tools/rtla/rtla-timerlat-top.rst
+++ b/Documentation/tools/rtla/rtla-timerlat-top.rst
@@ -127,7 +127,7 @@ SEE ALSO
--------
**rtla-timerlat**\(1), **rtla-timerlat-hist**\(1)
-*timerlat* tracer documentation: <https://www.kernel.org/doc/html/latest/trace/timerlat-tracer.html>
+`Timerlat tracer <https://docs.kernel.org/trace/timerlat-tracer.html>`__
AUTHOR
------
diff --git a/Documentation/tools/rtla/rtla-timerlat.rst b/Documentation/tools/rtla/rtla-timerlat.rst
index ce9f57e038c3..63718c52aa3f 100644
--- a/Documentation/tools/rtla/rtla-timerlat.rst
+++ b/Documentation/tools/rtla/rtla-timerlat.rst
@@ -45,7 +45,7 @@ SEE ALSO
========
**rtla-timerlat-top**\(1), **rtla-timerlat-hist**\(1)
-*timerlat* tracer documentation: <https://www.kernel.org/doc/html/latest/trace/timerlat-tracer.html>
+`Timerlat tracer <https://docs.kernel.org/trace/timerlat-tracer.html>`__
AUTHOR
======
--
2.53.0
^ permalink raw reply related
* [RFC PATCH v2 4/9] Docs/admin-guide/mm/damon/usage: document fail_charge_{num,denom} files
From: SeongJae Park @ 2026-04-05 15:12 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260405151232.102690-1-sj@kernel.org>
Update DAMON usage document for the DAMOS action failed regions quota
charge ratio control sysfs files.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/admin-guide/mm/damon/usage.rst | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index bfdb717441f05..d5548e460857c 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -84,7 +84,9 @@ comma (",").
│ │ │ │ │ │ │ │ sz/min,max
│ │ │ │ │ │ │ │ nr_accesses/min,max
│ │ │ │ │ │ │ │ age/min,max
- │ │ │ │ │ │ │ :ref:`quotas <sysfs_quotas>`/ms,bytes,reset_interval_ms,effective_bytes,goal_tuner
+ │ │ │ │ │ │ │ :ref:`quotas <sysfs_quotas>`/ms,bytes,reset_interval_ms,
+ │ │ │ │ │ │ │ effective_bytes,goal_tuner,
+ │ │ │ │ │ │ │ fail_charge_num,fail_charge_denom
│ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil
│ │ │ │ │ │ │ │ :ref:`goals <sysfs_schemes_quota_goals>`/nr_goals
│ │ │ │ │ │ │ │ │ 0/target_metric,target_value,current_value,nid,path
@@ -381,9 +383,10 @@ schemes/<N>/quotas/
The directory for the :ref:`quotas <damon_design_damos_quotas>` of the given
DAMON-based operation scheme.
-Under ``quotas`` directory, five files (``ms``, ``bytes``,
-``reset_interval_ms``, ``effective_bytes`` and ``goal_tuner``) and two
-directories (``weights`` and ``goals``) exist.
+Under ``quotas`` directory, seven files (``ms``, ``bytes``,
+``reset_interval_ms``, ``effective_bytes``, ``goal_tuner``, ``fail_charge_num``
+and ``fail_charge_denom``) and two directories (``weights`` and ``goals``)
+exist.
You can set the ``time quota`` in milliseconds, ``size quota`` in bytes, and
``reset interval`` in milliseconds by writing the values to the three files,
@@ -402,6 +405,13 @@ the background design of the feature and the name of the selectable algorithms.
Refer to :ref:`goals directory <sysfs_schemes_quota_goals>` for the goals
setup.
+You can set the action-failed memory quota charging ratio by writing the
+numerator and the denominator for the ratio to ``fail_charge_num`` and
+``fail_charge_denom`` files, respectively. Reading those files will return the
+current set values. Refer to :ref:`design
+<damon_design_damos_quotas_failed_memory_charging_ratio>` for more details of
+the ratio feature.
+
The time quota is internally transformed to a size quota. Between the
transformed size quota and user-specified size quota, smaller one is applied.
Based on the user-specified :ref:`goal <sysfs_schemes_quota_goals>`, the
--
2.47.3
^ permalink raw reply related
* [RFC PATCH v2 3/9] Docs/mm/damon/design: document fail_charge_{num,denom}
From: SeongJae Park @ 2026-04-05 15:12 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260405151232.102690-1-sj@kernel.org>
Update DAMON design document for the DAMOS action failed region quota
charge ratio.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/mm/damon/design.rst | 21 +++++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 510ec6375178d..3ea9c81b756c8 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -572,6 +572,27 @@ interface <sysfs_interface>`, refer to :ref:`weights <sysfs_quotas>` part of
the documentation.
+.. _damon_design_damos_quotas_failed_memory_charging_ratio:
+
+Action-failed Memory Charging Ratio
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+DAMOS action to a given region can fail for some subsets of the memory of the
+region. For example, if the action is ``pageout`` and the region has some
+unreclaimable pages, applying the action to the pages will fail. The amount of
+system resource that is taken for such failed action applications is usually
+different from that for successful action applications. For such cases, users
+can set different charging ratio for such failed memory. The ratio can be
+specified using ``fail_charge_num`` and ``fail_charge_denom`` parameters. The
+two parameters represent the numerator and denominator of the ratio.
+
+For example, let's suppose a DAMOS action is applied to a region of 1,000 MiB
+size. The action is successfully applied to only 700 MiB of the region.
+``fail_charge_num`` and ``fail_charge_denom`` are set to ``1`` and ``1024``,
+respectively. Then only 700 MiB and 300 KiB of size (``700 MiB + 300 MiB * 1 /
+1024``) will be charged.
+
+
.. _damon_design_damos_quotas_auto_tuning:
Aim-oriented Feedback-driven Auto-tuning
--
2.47.3
^ permalink raw reply related
* [RFC PATCH v2 0/9] mm/damon: introduce DAMOS failed region quota charge ratio
From: SeongJae Park @ 2026-04-05 15:12 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, Brendan Higgins,
David Gow, David Hildenbrand, Jonathan Corbet, Lorenzo Stoakes,
Michal Hocko, Mike Rapoport, Shuah Khan, Shuah Khan,
Suren Baghdasaryan, Vlastimil Babka, damon, kunit-dev, linux-doc,
linux-kernel, linux-kselftest, linux-mm
TL; DR: Let users set different DAMOS quota charge ratios for DAMOS
action failed regions, for deterministic and consistent DAMOS action
progress.
Common Reports: Unexpectedly Slow DAMOS
=======================================
One common issue report that we get from DAMON users is that DAMOS
action applying progress speed is sometimes much slower than expected.
And one common root cause is that the DAMOS quota is exceeded by the
action applying failed memory regions.
For example, a group of users tried to run DAMOS-based proactive memory
reclamation (DAMON_RECLAIM) with 100 MiB per second DAMOS quota. They
ran it on a system having no active workload which means all memory of
the system is cold. The expectation was that the system will show 100
MiB per second reclamation until (nearly) all memory is reclaimed. But
what they found is that the speed is quite inconsistent and sometimes it
becomes very slower than the expectation, sometimes even no reclamation
at all for about tens of seconds. The upper limit of the speed (100 MiB
per second) was being kept as expected, though.
By monitoring the qt_exceeds (number of DAMOS quota exceed events) DAMOS
stat, we found DAMOS quota is always exceeded when the speed is slow. By
monitoring sz_tried and sz_applied (the total amount of DAMOS action
tried memory and succeeded memory) DAMOS stats together, we found the
reclamation attempts nearly always failed when the speed is slow.
DAMOS quota charges DAMOS action tried regions regardless of the
successfulness of the try. Hence in the example reported case, there
was unreclaimable memory spread around the system memory. Sometimes
nearly 100 MiB of memory that DAMOS tried to reclaim in the given quota
interval was reclaimable, and therefore showed nearly 100 MiB per second
speed. Sometimes nearly 99 MiB of memory that DAMOS was trying to
reclaim in the given quota interval was unreclaimable, and therefore
showing only about 1 MiB per second reclaim speed.
We explained it is an expected behavior of the feature rather than a
bug, as DAMOS quota is there for only the upper-limit of the speed. The
users agreed and later reported a huge win from the adoption of
DAMON_RECLAIM on their products.
It is Not a Bug but a Feature; But...
=====================================
So nothing is broken. DAMOS quota is working as intended, as the upper
limit of the speed. It also provides its behavior observability via
DAMOS stat. In the real world production environment that runs long
term active workloads and matters stability, the speed sometimes being
slow is not a real problem.
But, the non-deterministic behavior is sometimes annoying, especially in
lab environments. Even in a realistic production environment, when
there is a huge amount of DAMOS action unapplicable memory, the speed
could be problematically slow. Let's suppose a virtual machines
provider that setup 99% of the host memory as hugetlb pages that cannot
be reclaimed, to give it to virtual machines. Also, when aim-oriented
DAMOS auto-tuning is applied, this could also make the internal feedback
loop confused.
The intention of the current behavior was that trying DAMOS action to
regions would anyway impose some overhead, and therefore somehow be
charged. But in the real world, the overhead for failed action is much
lighter than successful action. Charging those at the same ratio may be
unfair, or at least suboptimum in some environments.
DAMOS Action Failed Region Quota Charge Ratio
=============================================
Let users set the charge ratio for the action-failed memory, for more
optimal and deterministic use of DAMOS. It allows users to specify the
numerator and the denominator of the ratio for flexible setup. For
example, let's suppose the numerator and the denominator are set to 1
and 4,096, respectively. The ratio is 1 / 4,096. A DAMOS scheme action
is applied to 5 GiB memory. For 1 GiB of the memory, the action is
succeeded. For the rest (4 GiB), the action is failed. Then, only 1
GiB and 1 MiB quota is charged.
The optimal charge ratio will depend on the use case and
system/workload. I'd recommend starting from setting the nominator as 1
and the denominator as PAGE_SIZE and tune based on the results, because
many DAMOS actions are applied at page level.
Tests
=====
I tested this feature in the steps below.
1. Allocate 50% of system memory and mlock() it using a test program.
2. Fill up the page cache to exhaust nearly all free memory.
3. Start DAMON-based proactive reclamation with 100 MiB/second DAMOS
hard-quota. Auto-tune the DAMOS soft-quota under the hard-quota for
achieving 40% free memory of the system with 'temporal' tuner.
For step 1, I run a simple C program that is written by Gemini. It is
quite straightforward, so I'm not sharing the code here.
For step 2, I use dd command like below:
dd if=/dev/zero of=foo bs=1M count=$50_percent_of_system_memory
For step 3, I use the latest version of DAMON user-space tool (damo)
like below.
sudo damo start --damos_action pageout \
` # Do the pageout only up to 100 MiB per second ` \
--damos_quota_space 100M --damos_quota_interval 1s \
` # Auto-tune the quota below the hard quota aiming` \
` # 40% free memory of the node 0 ` \
` # (entire node of the test system)` \
--damos_quota_goal node_mem_free_bp 40% 0 \
` # use temporal tuner, which is easy to understnd ` \
--damos_quota_goal_tuner temporal
As expected, the progress of the reclamation is not consistent, because
the quota is exceeded for the failed reclamation of the unreclaimable
memory.
I do this again, but with the failed region charge ratio feature. For
this, the above 'damo' command is used, after appending command line
option for setup of the charge ratio like below. Note that the option
was added to 'damo' after v3.1.9.
sudo ./damo start --damos_action pageout \
[...]
` # quota-charge only 1/4096 for pageout-failed regions ` \
--damos_quota_fail_charge_ratio 1 4096
The progress of the reclamation was nearly 100 MiB per second until the
goal was achieved, meeting the expectation.
Patches Sequence
================
Patch 1 implements the feature and exposes it via DAMON core API.
Patch 2 implements DAMON sysfs ABI for the feature. Three following
patches (3-5) document the feature and ABI on design, usage, and ABI
documents, respectively. Four patches for testing of the new feature
follow. Patch 6 implements a kunit test for the feature. Patches 7
and 8 extend DAMON selftest helpers for DAMON sysfs control and internal
state dumping for adding a new selftest for the feature. Patch 9
extends existing DAMON sysfs interface selftest to test the new feature
using the extended helper scripts.
Changelog
=========
Changes from RFC v1
(https://lore.kernel.org/20260404163943.89278-1-sj@kernel.org)
- Avoid overflows in charge amount calculation.
- Fix/wordsmith documentation for grammar, typo, and wrong examples.
- Improve unit test for more consistent comparison source use.
SeongJae Park (9):
mm/damon/core: introduce failed region quota charge ratio
mm/damon/sysfs-schemes: implement fail_charge_{num,denom} files
Docs/mm/damon/design: document fail_charge_{num,denom}
Docs/admin-guide/mm/damon/usage: document fail_charge_{num,denom}
files
Docs/ABI/damon: document fail_charge_{num,denom}
mm/damon/tests/core-kunit: test fail_charge_{num,denom} committing
selftets/damon/_damon_sysfs: support failed region quota charge ratio
selftests/damon/drgn_dump_damon_status: support failed region quota
charge ratio
selftets/damon/sysfs.py: test failed region quota charge ratio
.../ABI/testing/sysfs-kernel-mm-damon | 12 +++++
Documentation/admin-guide/mm/damon/usage.rst | 18 +++++--
Documentation/mm/damon/design.rst | 21 ++++++++
include/linux/damon.h | 9 ++++
mm/damon/core.c | 21 +++++++-
mm/damon/sysfs-schemes.c | 54 +++++++++++++++++++
mm/damon/tests/core-kunit.h | 6 +++
tools/testing/selftests/damon/_damon_sysfs.py | 21 +++++++-
.../selftests/damon/drgn_dump_damon_status.py | 2 +
tools/testing/selftests/damon/sysfs.py | 6 +++
10 files changed, 163 insertions(+), 7 deletions(-)
base-commit: 36eed23041e834175ca57dc38ac0e128808b1abb
--
2.47.3
^ permalink raw reply
* Re: [PATCH v3 2/2] docs: add advanced search benchmark harness and instrumentation
From: kernel test robot @ 2026-04-05 12:43 UTC (permalink / raw)
To: Rito Rhymes, corbet, skhan
Cc: oe-kbuild-all, linux-doc, linux-kernel, Rito Rhymes
In-Reply-To: <20260404073413.32309-3-rito@ritovision.com>
Hi Rito,
kernel test robot noticed the following build warnings:
[auto build test WARNING on lwn/docs-next]
[also build test WARNING on linus/master v7.0-rc6 next-20260403]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Rito-Rhymes/docs-add-advanced-search-for-kernel-documentation/20260405-132032
base: git://git.lwn.net/linux.git docs-next
patch link: https://lore.kernel.org/r/20260404073413.32309-3-rito%40ritovision.com
patch subject: [PATCH v3 2/2] docs: add advanced search benchmark harness and instrumentation
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260405/202604051424.8oinrnwW-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604051424.8oinrnwW-lkp@intel.com/
All warnings (new ones prefixed by >>):
Warning: Documentation/devicetree/bindings/mfd/motorola-cpcap.txt references a file that doesn't exist: Documentation/devicetree/bindings/rtc/cpcap-rtc.txt
Warning: Documentation/devicetree/bindings/regulator/siliconmitus,sm5703-regulator.yaml references a file that doesn't exist: Documentation/devicetree/bindings/mfd/siliconmitus,sm5703.yaml
Warning: Documentation/devicetree/bindings/rtc/motorola,cpcap-rtc.yaml references a file that doesn't exist: Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml
Warning: Documentation/doc-guide/parse-headers.rst references a file that doesn't exist: Documentation/userspace-api/media/Makefile
Warning: Documentation/leds/leds-lp5812.rst references a file that doesn't exist: Documentation/ABI/testing/sysfs-class-led-multicolor.rst
>> Warning: Documentation/sphinx-static/kernel-search.js references a file that doesn't exist: Documentation/search.html
Warning: Documentation/translations/it_IT/doc-guide/parse-headers.rst references a file that doesn't exist: Documentation/userspace-api/media/Makefile
Warning: Documentation/translations/ja_JP/SubmittingPatches references a file that doesn't exist: linux-2.6.12-vanilla/Documentation/dontdiff
Warning: Documentation/translations/ja_JP/process/submit-checklist.rst references a file that doesn't exist: Documentation/translations/ja_JP/SubmitChecklist
Warning: Documentation/translations/zh_CN/doc-guide/parse-headers.rst references a file that doesn't exist: Documentation/userspace-api/media/Makefile
Warning: Documentation/translations/zh_CN/filesystems/gfs2-glocks.rst references a file that doesn't exist: Documentation/filesystems/gfs2-glocks.rst
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v3 2/2] Documentation: drm: Remove drm_atomic_state rename entry
From: kernel test robot @ 2026-04-05 11:32 UTC (permalink / raw)
To: Maxime Ripard, David Airlie, Simona Vetter, Maarten Lankhorst,
Thomas Zimmermann, Jonathan Corbet
Cc: oe-kbuild-all, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Alex Deucher, Christian König, Rob Clark,
Dmitry Baryshkov, Andrzej Hajda, Neil Armstrong, Robert Foss,
Dave Stevenson, Laurent Pinchart, dri-devel, linux-doc,
Maxime Ripard, Luca Ceresoli
In-Reply-To: <20260402-drm-drm-atomic-update-v3-2-b826f51ac511@kernel.org>
Hi Maxime,
kernel test robot noticed the following build warnings:
[auto build test WARNING on 9bdbf7eb25b3121ef19533df4fb70f2c39fc0d6a]
url: https://github.com/intel-lab-lkp/linux/commits/Maxime-Ripard/drm-Rename-struct-drm_atomic_state-to-drm_atomic_commit/20260405-115623
base: 9bdbf7eb25b3121ef19533df4fb70f2c39fc0d6a
patch link: https://lore.kernel.org/r/20260402-drm-drm-atomic-update-v3-2-b826f51ac511%40kernel.org
patch subject: [PATCH v3 2/2] Documentation: drm: Remove drm_atomic_state rename entry
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260405/202604051325.jSSmpYZj-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604051325.jSSmpYZj-lkp@intel.com/
All warnings (new ones prefixed by >>):
Examples
~~~~~~~~ [docutils]
>> Documentation/gpu/komeda-kms.rst:420: WARNING: Title underline too short.
vim +420 Documentation/gpu/komeda-kms.rst
557c37360eca86 james qian wang (Arm Technology China 2019-01-03 408)
557c37360eca86 james qian wang (Arm Technology China 2019-01-03 409) struct komeda_component {
557c37360eca86 james qian wang (Arm Technology China 2019-01-03 410) struct drm_private_obj obj;
557c37360eca86 james qian wang (Arm Technology China 2019-01-03 411) ...
557c37360eca86 james qian wang (Arm Technology China 2019-01-03 412) }
557c37360eca86 james qian wang (Arm Technology China 2019-01-03 413)
557c37360eca86 james qian wang (Arm Technology China 2019-01-03 414) struct komeda_pipeline {
557c37360eca86 james qian wang (Arm Technology China 2019-01-03 415) struct drm_private_obj obj;
557c37360eca86 james qian wang (Arm Technology China 2019-01-03 416) ...
557c37360eca86 james qian wang (Arm Technology China 2019-01-03 417) }
557c37360eca86 james qian wang (Arm Technology China 2019-01-03 418)
77e56dfef2e28b Maxime Ripard 2026-04-02 419 Tracking component_state/pipeline_state by drm_atomic_commit
557c37360eca86 james qian wang (Arm Technology China 2019-01-03 @420) -----------------------------------------------------------
557c37360eca86 james qian wang (Arm Technology China 2019-01-03 421)
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v6 3/4] iio: adc: ad4691: add triggered buffer support
From: Andy Shevchenko @ 2026-04-05 8:57 UTC (permalink / raw)
To: David Lechner
Cc: radu.sabau, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan, linux-iio, devicetree,
linux-kernel, linux-pwm, linux-gpio, linux-doc
In-Reply-To: <e38e5b97-e90f-4613-a15e-6c3d08cd77f7@baylibre.com>
On Sat, Apr 04, 2026 at 10:12:04AM -0500, David Lechner wrote:
> On 4/3/26 6:03 AM, Radu Sabau via B4 Relay wrote:
> > Add buffered capture support using the IIO triggered buffer framework.
> >
> > CNV Burst Mode: the GP pin identified by interrupt-names in the device
> > tree is configured as DATA_READY output. The IRQ handler stops
> > conversions and fires the IIO trigger; the trigger handler executes a
> > pre-built SPI message that reads all active channels from the AVG_IN
> > accumulator registers and then resets accumulator state and restarts
> > conversions for the next cycle.
> >
> > Manual Mode: CNV is tied to SPI CS so each transfer simultaneously
> > reads the previous result and starts the next conversion (pipelined
> > N+1 scheme). At preenable time a pre-built, optimised SPI message of
> > N+1 transfers is constructed (N channel reads plus one NOOP to drain
> > the pipeline). The trigger handler executes the message in a single
> > spi_sync() call and collects the results. An external trigger (e.g.
> > iio-trig-hrtimer) is required to drive the trigger at the desired
> > sample rate.
> >
> > Both modes share the same trigger handler and push a complete scan —
> > one u16 slot per channel at its scan_index position, followed by a
> > timestamp — to the IIO buffer via iio_push_to_buffers_with_ts().
> >
> > The CNV Burst Mode sampling frequency (PWM period) is exposed as a
> > buffer-level attribute via IIO_DEVICE_ATTR.
Tried my best to avoid clashes with David's review.
...
> > #include <linux/array_size.h>
> > #include <linux/bitfield.h>
> > +#include <linux/bitmap.h>
> > #include <linux/bitops.h>
When bitmap.h is present, it implies bitops.h, hence the latter can be simply
replaced.
> > #include <linux/cleanup.h>
> > #include <linux/delay.h>
> > #include <linux/dev_printk.h>
> > #include <linux/device/devres.h>
> > #include <linux/err.h>
> > +#include <linux/interrupt.h>
> > #include <linux/math.h>
> > #include <linux/module.h>
> > #include <linux/mod_devicetable.h>
> > +#include <linux/property.h>
> > +#include <linux/pwm.h>
> > #include <linux/regmap.h>
> > #include <linux/regulator/consumer.h>
> > #include <linux/reset.h>
...
> > .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) \
> > - | BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> > + | BIT(IIO_CHAN_INFO_SAMP_FREQ) \
> > + | BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
> > .info_mask_separate_available = \
> > - BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> > + BIT(IIO_CHAN_INFO_SAMP_FREQ) \
> > + | BIT(IIO_CHAN_INFO_OVERSAMPLING_RATIO), \
You may reduce churn by squeezing a new ones in between existing ones.
Also consider use usual patter of placing the operator on the same line where
left operand is (currently it goes with the right operand).
...
> > struct ad4691_state {
Just to double check, when add a new field or fields into the data structure
check with `pahole` that the new members placed at the best or at least good
enough locations.
> > const struct ad4691_chip_info *info;
> > struct regmap *regmap;
> > +
> > + struct pwm_device *conv_trigger;
> > + int irq;
> > +
> > + bool manual_mode;
> > +
> > int vref_uV;
> > + u8 osr[16];
> > bool refbuf_en;
> > bool ldo_en;
> > + u32 cnv_period_ns;
> > /*
> > * Synchronize access to members of the driver state, and ensure
> > * atomicity of consecutive SPI operations.
> > */
> > struct mutex lock;
> > + /*
> > + * Per-buffer-enable lifetime resources:
> > + * Manual Mode - a pre-built SPI message that clocks out N+1
> > + * transfers in one go.
> > + * CNV Burst Mode - a pre-built SPI message that clocks out 2*N
> > + * transfers in one go.
> > + */
> > + struct spi_message scan_msg;
> > + struct spi_transfer *scan_xfers;
> > + __be16 *scan_tx;
> > + __be16 *scan_rx;
>
> Why not embed these arrays here? Then we don't have to deal with
> alloc/free later.
>
> > + /* Scan buffer: one slot per channel plus timestamp */
> > + struct {
> > + u16 vals[16];
> > + aligned_s64 ts;
> > + } scan __aligned(IIO_DMA_MINALIGN);
>
> Better would be IIO_DECLARE_BUFFER_WITH_TS() since we don't always
> use all vals.
>
> Also, current usage doesn't need to be DMA-safe because scan_tx
> is being used for the actual SPI xfer.
>
> > };
...
> > +static int ad4691_gpio_setup(struct ad4691_state *st, unsigned int gp_num)
> > +{
> > + unsigned int shift = 4 * (gp_num % 2);
> > +
> > + return regmap_update_bits(st->regmap,
> > + AD4691_GPIO_MODE1_REG + gp_num / 2,
> > + AD4691_GP_MODE_MASK << shift,
> > + AD4691_GP_MODE_DATA_READY << shift);
Not sure if compiler will see % and / together, I would go with two more
temporary variables to make it clear to it:
... _bit_off = % 2;
... _reg_off = / 2;
The practical example is described, for example, here:
9b3cd5c7099f ("regmap: place foo / 8 and foo % 8 closer to each other").
> > +}
...
> > +static int ad4691_manual_buffer_preenable(struct iio_dev *indio_dev)
> > +{
> > + struct ad4691_state *st = iio_priv(indio_dev);
> > + struct device *dev = regmap_get_device(st->regmap);
> > + struct spi_device *spi = to_spi_device(dev);
> > + unsigned int n_active = bitmap_weight(indio_dev->active_scan_mask,
> > + iio_get_masklength(indio_dev));
In such cases please split definition and assignment. Will take two lines, but
readability will be better.
> > + unsigned int n_xfers = n_active + 1;
> > + unsigned int k, i;
> > + int ret;
> > +
> > + st->scan_xfers = kcalloc(n_xfers, sizeof(*st->scan_xfers), GFP_KERNEL);
>
> Usually, we make st->scan_xfers a fixed array with the max number of possible
> xfers. Then we don't have to deal with alloc/free.
And please if it's still be required to allocate and possible use kzalloc_objs().
> > + if (!st->scan_xfers)
> > + return -ENOMEM;
> > +
> > + st->scan_tx = kcalloc(n_xfers, sizeof(*st->scan_tx), GFP_KERNEL);
> > + if (!st->scan_tx) {
> > + kfree(st->scan_xfers);
> > + return -ENOMEM;
> > + }
> > +
> > + st->scan_rx = kcalloc(n_xfers, sizeof(*st->scan_rx), GFP_KERNEL);
> > + if (!st->scan_rx) {
> > + kfree(st->scan_tx);
> > + kfree(st->scan_xfers);
> > + return -ENOMEM;
> > + }
> > +
> > + spi_message_init(&st->scan_msg);
> > +
> > + k = 0;
> > + iio_for_each_active_channel(indio_dev, i) {
> > + st->scan_tx[k] = cpu_to_be16(AD4691_ADC_CHAN(i));
> > + st->scan_xfers[k].tx_buf = &st->scan_tx[k];
> > + st->scan_xfers[k].rx_buf = &st->scan_rx[k];
> > + st->scan_xfers[k].len = sizeof(__be16);
> > + st->scan_xfers[k].cs_change = 1;
> > + spi_message_add_tail(&st->scan_xfers[k], &st->scan_msg);
> > + k++;
> > + }
> > +
> > + /* Final NOOP transfer to retrieve last channel's result. */
> > + st->scan_tx[k] = cpu_to_be16(AD4691_NOOP);
> > + st->scan_xfers[k].tx_buf = &st->scan_tx[k];
> > + st->scan_xfers[k].rx_buf = &st->scan_rx[k];
> > + st->scan_xfers[k].len = sizeof(__be16);
> > + spi_message_add_tail(&st->scan_xfers[k], &st->scan_msg);
> > +
> > + st->scan_msg.spi = spi;
>
> This isn't how the SPI framework is intended to be used. We should
> have st->spi = spi in probe instead.
>
> > +
> > + ret = spi_optimize_message(spi, &st->scan_msg);
> > + if (ret) {
> > + ad4691_free_scan_bufs(st);
> > + return ret;
> > + }
> > +
> > + ret = ad4691_enter_conversion_mode(st);
> > + if (ret) {
> > + spi_unoptimize_message(&st->scan_msg);
> > + ad4691_free_scan_bufs(st);
> > + return ret;
> > + }
> > +
> > + return 0;
> > +}
...
> > +static int ad4691_cnv_burst_buffer_preenable(struct iio_dev *indio_dev)
As per above.
...
> > +static ssize_t sampling_frequency_show(struct device *dev,
> > + struct device_attribute *attr,
> > + char *buf)
> > +{
> > + struct iio_dev *indio_dev = dev_to_iio_dev(dev);
> > + struct ad4691_state *st = iio_priv(indio_dev);
> > +
> > + return sysfs_emit(buf, "%u\n", (u32)(NSEC_PER_SEC / st->cnv_period_ns));
Why casting?
> > +}
...
> > +static IIO_DEVICE_ATTR(sampling_frequency, 0644,
> > + sampling_frequency_show,
> > + sampling_frequency_store, 0);
IIO_DEVICE_ATTR_RW().
...
> > +static int ad4691_read_scan(struct iio_dev *indio_dev, s64 timestamp)
> > +{
> > + struct ad4691_state *st = iio_priv(indio_dev);
> > + unsigned int i, k = 0;
> > + int ret;
> > +
> > + guard(mutex)(&st->lock);
> > +
> > + ret = spi_sync(st->scan_msg.spi, &st->scan_msg);
> > + if (ret)
> > + return ret;
> > +
> > + if (st->manual_mode) {
> > + iio_for_each_active_channel(indio_dev, i) {
> > + st->scan.vals[i] = be16_to_cpu(st->scan_rx[k + 1]);
> > + k++;
> > + }
> > + } else {
> > + iio_for_each_active_channel(indio_dev, i) {
> > + st->scan.vals[i] = be16_to_cpu(st->scan_rx[k]);
> > + k++;
> > + }
>
> I suppose this is fine, but we usually try to avoid extra copiying and
> byte swapping of bufferes like this if we can. It seems completly doable
> in both modes. Manual mode will just one extra two-byte buffer for the
> throw-away conversion on the first read xfer (or just write to the same
> element twice).
And in case it's still needed, we may introduce a helper in
include/linux/byteorder/generic.h calling it memcpy_to/from_be16().
> > + ret = regmap_write(st->regmap, AD4691_STATE_RESET_REG,
> > + AD4691_STATE_RESET_ALL);
> > + if (ret)
> > + return ret;
> > +
> > + ret = ad4691_sampling_enable(st, true);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + iio_push_to_buffers_with_ts(indio_dev, &st->scan, sizeof(st->scan),
> > + timestamp);
> > + return 0;
> > +}
...
> > +static int ad4691_setup_triggered_buffer(struct iio_dev *indio_dev,
> > + struct ad4691_state *st)
> > +{
> > + struct device *dev = regmap_get_device(st->regmap);
> > + struct iio_trigger *trig;
> > + unsigned int i;
> > + int irq, ret;
> > +
> > + trig = devm_iio_trigger_alloc(dev, "%s-dev%d",
> > + indio_dev->name,
> > + iio_device_id(indio_dev));
> > + if (!trig)
> > + return -ENOMEM;
> > +
> > + trig->ops = &ad4691_trigger_ops;
> > + iio_trigger_set_drvdata(trig, st);
> > +
> > + ret = devm_iio_trigger_register(dev, trig);
> > + if (ret)
> > + return dev_err_probe(dev, ret, "IIO trigger register failed\n");
> > +
> > + indio_dev->trig = iio_trigger_get(trig);
> > +
> > + if (!st->manual_mode) {
>
> I would invert the if since the other case is shorter.
+1.
> > + /*
> > + * The GP pin named in interrupt-names asserts at end-of-conversion.
> > + * The IRQ handler stops conversions and fires the IIO trigger so
> > + * the trigger handler can read and push the sample to the buffer.
> > + * The IRQ is kept disabled until the buffer is enabled.
> > + */
> > + irq = -ENODEV;
> > + for (i = 0; i < ARRAY_SIZE(ad4691_gp_names); i++) {
> > + irq = fwnode_irq_get_byname(dev_fwnode(dev),
> > + ad4691_gp_names[i]);
> > + if (irq > 0)
> > + break;
> > + }
> > + if (irq <= 0)
> > + return dev_err_probe(dev, irq < 0 ? irq : -ENODEV,
> > + "failed to get GP interrupt\n");
>
> Usually we would usually just use spi->irq since it already
> has been looked up. But I guess it is OK to do it like this.
No, it's not. (Linux) IRQ shouldn't ever be 0, so this check is effectively a
dead code.
irq = -ENXIO; // Note, this is the error code used by core for
// IRQ not found.
...
if (irq < 0)
return dev_err_probe(dev, irq, "failed to get GP interrupt\n");
> > + st->irq = irq;
> > +
> > + ret = ad4691_gpio_setup(st, i);
> > + if (ret)
> > + return ret;
> > +
> > + /*
> > + * IRQ is kept disabled until the buffer is enabled to prevent
> > + * spurious DATA_READY events before the SPI message is set up.
> > + */
> > + ret = devm_request_threaded_irq(dev, irq, NULL,
> > + &ad4691_irq,
> > + IRQF_ONESHOT | IRQF_NO_AUTOEN,
> > + indio_dev->name, indio_dev);
> > + if (ret)
> > + return ret;
> > +
> > + return devm_iio_triggered_buffer_setup_ext(dev, indio_dev,
> > + &iio_pollfunc_store_time,
> > + &ad4691_trigger_handler,
> > + IIO_BUFFER_DIRECTION_IN,
> > + &ad4691_cnv_burst_buffer_setup_ops,
> > + ad4691_buffer_attrs);
> > + }
> > +
> > + return devm_iio_triggered_buffer_setup(dev, indio_dev,
> > + &iio_pollfunc_store_time,
> > + &ad4691_trigger_handler,
> > + &ad4691_manual_buffer_setup_ops);
> > +}
> > +
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v9 00/10] VMSCAPE optimization for BHI variant
From: Pawan Gupta @ 2026-04-05 7:23 UTC (permalink / raw)
To: David Laight
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
Andy Lutomirski, Thomas Gleixner, Ingo Molnar, David Ahern,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, Stanislav Fomichev, Hao Luo, Paolo Bonzini,
Jonathan Corbet, linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf,
netdev, linux-doc
In-Reply-To: <20260404162059.34ca90df@pumpkin>
On Sat, Apr 04, 2026 at 04:20:59PM +0100, David Laight wrote:
> On Thu, 2 Apr 2026 17:30:32 -0700
> Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:
>
> > v9:
> > - Use global variables for BHB loop counters instead of ALTERNATIVE-based
> > approach. (Dave & others)
> > - Use 32-bit registers (%eax/%ecx) for loop counters, loaded via movzbl
> > from 8-bit globals. 8-bit registers (e.g. %ah in the inner loop) caused
> > performance regression on certain CPUs due to partial-register stalls. (David Laight)
> > - Let BPF save/restore %rax/%rcx as in the original implementation, since
> > it is the only caller that needs these registers preserved across the
> > BHB clearing sequence.
>
> That is as dangerous as hell...
> Does BPF even save %rcx - I'm sure I checked that a long time ago
> and found it didn't.
Below code injects save/restore of %rax and %rcx to BPF programs:
arch/x86/net/bpf_jit_comp.c
emit_spectre_bhb_barrier()
{
u8 *prog = *pprog;
u8 *func;
if (cpu_feature_enabled(X86_FEATURE_CLEAR_BHB_LOOP)) {
/* The clearing sequence clobbers eax and ecx. */
EMIT1(0x50); /* push rax */
EMIT1(0x51); /* push rcx */
ip += 2;
func = (u8 *)clear_bhb_loop_nofence;
ip += x86_call_depth_emit_accounting(&prog, func, ip);
if (emit_call(&prog, func, ip))
return -EINVAL;
/* Don't speculate past this until BHB is cleared */
EMIT_LFENCE();
EMIT1(0x59); /* pop rcx */
EMIT1(0x58); /* pop rax */
}
...
> (I'm mostly AFK over Easter and can't check.)
> A least there should be a blood great big comment that BPF calls this code
> and only saves specific registers.
Sure, will add.
> But given the number of mispredicted branches and other pipeline stalls
> in this code a couple of register saves to stack are unlikely to make
> any difference.
BPF programs have been saving/restoring the registers since long now. What
problem are you anticipating?
^ permalink raw reply
* Re: [PATCH v3 0/2] docs: advanced search with benchmark harness
From: Randy Dunlap @ 2026-04-05 5:51 UTC (permalink / raw)
To: Rito Rhymes; +Cc: linux-doc, linux-kernel
In-Reply-To: <DHK7FY79AOJW.AC6LHU703AIR@ritovision.com>
Hi,
On 4/4/26 12:50 AM, Rito Rhymes wrote:
> Randy, I meant to include you on the v3 reroll; this new version is
> intended to address the compatibility issue you hit earlier in our
> initial test and debugging (among other improvements).
>
> I believe the problem came from version-dependent differences in the
> generated Sphinx search data, so this reroll hardens the compatibility
> handling around those differences and the search logic that consumes the
> data.
>
> If you have time to try it again with the setup that exposed the
> problem before, I would appreciate confirmation that the updated
> version behaves correctly there.
>
> I would also appreciate your broader assessment of the feature:
> whether it seems genuinely useful in practice, how large the benefit is
> relative to the current Quick Search interface, how many other users you
> think would benefit from it, and whether you see any remaining issues or
> obvious room for improvement.
I like it. I think it's useful -- the old search could give a bit too much
output. The search result tabs (groups) are helpful.
But it will be up to Jon whether its usefulness exceeds its complications.
Also, I'm not sure that Linux developer mailing lists will reach the right
audience for feedback about this change.
I mostly use 'grep' for searching Documentation/ and I expect lots of other
developers also do that (if they bother to look). So I don't know who will
be the largest user(s) of this feature. I.e., I don't know who uses
docs.kernel.org.
I do notice under the Pages tab that all of the pages listed say
"Summary unavailable." I don't know what should be there instead
of that message.
--
~Randy
^ permalink raw reply
* Re: [PATCH] docs: fix typos and duplicated words across documentation
From: Bagas Sanjaya @ 2026-04-05 5:01 UTC (permalink / raw)
To: Randy Dunlap, Manuel Cortez, linux-doc; +Cc: corbet
In-Reply-To: <8e489ff9-e9f8-4924-ad92-a1dbd6d33121@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1186 bytes --]
On Sat, Apr 04, 2026 at 08:16:05PM -0700, Randy Dunlap wrote:
> Hi,
>
> This last one is a little awkward as is but dropping one "in" doesn't help it --
> it harms it (i.e., it's correct as is but could possibly be improved.)
>
> > diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst
> > index 2966b7122f05..948bce44ca9b 100644
> > --- a/Documentation/networking/switchdev.rst
> > +++ b/Documentation/networking/switchdev.rst
> > @@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by
> > monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
> > bond will see its upper master change. If that bond is moved into a bridge,
> > the bond's upper master will change. And so on. The driver will track such
> > -movements to know what position a port is in in the overall topology by
> > +movements to know what position a port is in the overall topology by
I think it can be reworded as "The driver will track movements to locate
the port's position in the overall topology ...".
Thanks.
--
An old man doll... just what I always wanted! - Clara
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] docs: fix typos and duplicated words across documentation
From: Randy Dunlap @ 2026-04-05 3:16 UTC (permalink / raw)
To: Manuel Cortez, linux-doc; +Cc: corbet
In-Reply-To: <20260405030359.7392-1-mdjesuscv@gmail.com>
Hi,
On 4/4/26 8:03 PM, Manuel Cortez wrote:
> Fix the following typos and duplicated words:
>
> - admin-guide/pm/intel-speed-select.rst: "weather" -> "whether"
> - core-api/real-time/differences.rst: "the the" -> "the"
> - admin-guide/bcache.rst: "to to" -> "to"
> - networking/switchdev.rst: "is in in" -> "is in"
>
> Signed-off-by: Manuel Cortez <mdjesuscv@gmail.com>
> ---
> Documentation/admin-guide/bcache.rst | 2 +-
> Documentation/admin-guide/pm/intel-speed-select.rst | 2 +-
> Documentation/core-api/real-time/differences.rst | 2 +-
> Documentation/networking/switchdev.rst | 2 +-
> 4 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/admin-guide/bcache.rst b/Documentation/admin-guide/bcache.rst
> index f71f349553e4..325816edbdab 100644
> --- a/Documentation/admin-guide/bcache.rst
> +++ b/Documentation/admin-guide/bcache.rst
> @@ -618,7 +618,7 @@ cache_replacement_policy
> One of either lru, fifo or random.
>
> freelist_percent
> - Size of the freelist as a percentage of nbuckets. Can be written to to
> + Size of the freelist as a percentage of nbuckets. Can be written to
> increase the number of buckets kept on the freelist, which lets you
> artificially reduce the size of the cache at runtime. Mostly for testing
> purposes (i.e. testing how different size caches affect your hit rate).
> diff --git a/Documentation/admin-guide/pm/intel-speed-select.rst b/Documentation/admin-guide/pm/intel-speed-select.rst
> index a2bfb971654f..dec2a25f10bc 100644
> --- a/Documentation/admin-guide/pm/intel-speed-select.rst
> +++ b/Documentation/admin-guide/pm/intel-speed-select.rst
> @@ -287,7 +287,7 @@ level.
> Check presence of other Intel(R) SST features
> ---------------------------------------------
>
> -Each of the performance profiles also specifies weather there is support of
> +Each of the performance profiles also specifies whether there is support of
> other two Intel(R) SST features (Intel(R) Speed Select Technology - Base Frequency
> (Intel(R) SST-BF) and Intel(R) Speed Select Technology - Turbo Frequency (Intel
> SST-TF)).
> diff --git a/Documentation/core-api/real-time/differences.rst b/Documentation/core-api/real-time/differences.rst
> index 83ec9aa1c61a..a129570dab5a 100644
> --- a/Documentation/core-api/real-time/differences.rst
> +++ b/Documentation/core-api/real-time/differences.rst
> @@ -213,7 +213,7 @@ to suspend until the callback completes, ensuring forward progress without
> risking livelock.
>
> In order to solve the problem at the API level, the sequence locks were extended
> -to allow a proper handover between the the spinning reader and the maybe
> +to allow a proper handover between the spinning reader and the maybe
> blocked writer.
>
> Sequence locks
Those first 3 look good.
Just a matter of how they get merged.
This last one is a little awkward as is but dropping one "in" doesn't help it --
it harms it (i.e., it's correct as is but could possibly be improved.)
> diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst
> index 2966b7122f05..948bce44ca9b 100644
> --- a/Documentation/networking/switchdev.rst
> +++ b/Documentation/networking/switchdev.rst
> @@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by
> monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
> bond will see its upper master change. If that bond is moved into a bridge,
> the bond's upper master will change. And so on. The driver will track such
> -movements to know what position a port is in in the overall topology by
> +movements to know what position a port is in the overall topology by
> registering for netdevice events and acting on NETDEV_CHANGEUPPER.
>
> L2 Forwarding Offload
--
~Randy
^ permalink raw reply
* [PATCH] docs: fix typos and duplicated words across documentation
From: Manuel Cortez @ 2026-04-05 3:03 UTC (permalink / raw)
To: linux-doc; +Cc: corbet, Manuel Cortez
Fix the following typos and duplicated words:
- admin-guide/pm/intel-speed-select.rst: "weather" -> "whether"
- core-api/real-time/differences.rst: "the the" -> "the"
- admin-guide/bcache.rst: "to to" -> "to"
- networking/switchdev.rst: "is in in" -> "is in"
Signed-off-by: Manuel Cortez <mdjesuscv@gmail.com>
---
Documentation/admin-guide/bcache.rst | 2 +-
Documentation/admin-guide/pm/intel-speed-select.rst | 2 +-
Documentation/core-api/real-time/differences.rst | 2 +-
Documentation/networking/switchdev.rst | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/bcache.rst b/Documentation/admin-guide/bcache.rst
index f71f349553e4..325816edbdab 100644
--- a/Documentation/admin-guide/bcache.rst
+++ b/Documentation/admin-guide/bcache.rst
@@ -618,7 +618,7 @@ cache_replacement_policy
One of either lru, fifo or random.
freelist_percent
- Size of the freelist as a percentage of nbuckets. Can be written to to
+ Size of the freelist as a percentage of nbuckets. Can be written to
increase the number of buckets kept on the freelist, which lets you
artificially reduce the size of the cache at runtime. Mostly for testing
purposes (i.e. testing how different size caches affect your hit rate).
diff --git a/Documentation/admin-guide/pm/intel-speed-select.rst b/Documentation/admin-guide/pm/intel-speed-select.rst
index a2bfb971654f..dec2a25f10bc 100644
--- a/Documentation/admin-guide/pm/intel-speed-select.rst
+++ b/Documentation/admin-guide/pm/intel-speed-select.rst
@@ -287,7 +287,7 @@ level.
Check presence of other Intel(R) SST features
---------------------------------------------
-Each of the performance profiles also specifies weather there is support of
+Each of the performance profiles also specifies whether there is support of
other two Intel(R) SST features (Intel(R) Speed Select Technology - Base Frequency
(Intel(R) SST-BF) and Intel(R) Speed Select Technology - Turbo Frequency (Intel
SST-TF)).
diff --git a/Documentation/core-api/real-time/differences.rst b/Documentation/core-api/real-time/differences.rst
index 83ec9aa1c61a..a129570dab5a 100644
--- a/Documentation/core-api/real-time/differences.rst
+++ b/Documentation/core-api/real-time/differences.rst
@@ -213,7 +213,7 @@ to suspend until the callback completes, ensuring forward progress without
risking livelock.
In order to solve the problem at the API level, the sequence locks were extended
-to allow a proper handover between the the spinning reader and the maybe
+to allow a proper handover between the spinning reader and the maybe
blocked writer.
Sequence locks
diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst
index 2966b7122f05..948bce44ca9b 100644
--- a/Documentation/networking/switchdev.rst
+++ b/Documentation/networking/switchdev.rst
@@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by
monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
bond will see its upper master change. If that bond is moved into a bridge,
the bond's upper master will change. And so on. The driver will track such
-movements to know what position a port is in in the overall topology by
+movements to know what position a port is in the overall topology by
registering for netdevice events and acting on NETDEV_CHANGEUPPER.
L2 Forwarding Offload
--
2.51.0
^ permalink raw reply related
* Re: (sashiko status) [RFC PATCH 0/9] mm/damon: introduce DAMOS failed region quota charge ratio
From: SeongJae Park @ 2026-04-04 21:06 UTC (permalink / raw)
To: SeongJae Park
Cc: damon, kunit-dev, linux-doc, linux-kernel, linux-kselftest,
linux-mm
In-Reply-To: <20260404163943.89278-1-sj@kernel.org>
Dropped individuals from Cc list to reduce the traffic.
TL; DR: sashiko made a few useful findings. I will address those in the next
revision.
Forwarding sashiko.dev review status for the overall picture. Read my replies
to 'ISSUES MAY FOUND' patches for more details.
# review url: https://sashiko.dev/#/patchset/20260404163943.89278-1-sj@kernel.org
- [RFC PATCH 1/9] mm/damon/core: introduce failed region quota charge ratio
- status: Reviewed
- review: ISSUES MAY FOUND
- [RFC PATCH 2/9] mm/damon/sysfs-schemes: implement fail_charge_{num,denom} files
- status: Reviewed
- review: ISSUES MAY FOUND
- [RFC PATCH 3/9] Docs/mm/damon/design: document fail_charge_{num,denom}
- status: Reviewed
- review: ISSUES MAY FOUND
- [RFC PATCH 4/9] Docs/admin-guide/mm/damon/usage: document fail_charge_{num,denom} files
- status: Reviewed
- review: ISSUES MAY FOUND
- [RFC PATCH 5/9] Docs/ABI/damon: document fail_charge_{num,denom}
- status: Reviewed
- review: No issues found.
- [RFC PATCH 6/9] mm/damon/tests/core-kunit: test fail_charge_{num,denom} committing
- status: Reviewed
- review: ISSUES MAY FOUND
- [RFC PATCH 7/9] selftets/damon/_damon_sysfs: support failed region quota charge ratio
- status: Reviewed
- review: No issues found.
- [RFC PATCH 8/9] selftests/damon/drgn_dump_damon_status: support failed region quota charge ratio
- status: Reviewed
- review: No issues found.
- [RFC PATCH 9/9] selftets/damon/sysfs.py: test failed region quota charge ratio
- status: Reviewed
- review: No issues found.
# hkml [1] generated a draft of this mail. It can be regenerated
# using below command:
#
# hkml patch sashiko_dev --thread_status --for_forwarding \
# 20260404163943.89278-1-sj@kernel.org
#
# [1] https://github.com/sjp38/hackermail
Thanks,
SJ
^ permalink raw reply
* Re: (sashiko review) [RFC PATCH 4/9] Docs/admin-guide/mm/damon/usage: document fail_charge_{num,denom} files
From: SeongJae Park @ 2026-04-04 21:01 UTC (permalink / raw)
To: SeongJae Park; +Cc: damon, linux-doc, linux-kernel, linux-mm
In-Reply-To: <20260404163943.89278-5-sj@kernel.org>
Dropped individual recipients from Cc list, to reduce unnecessary traffic.
TL; DR: sashiko found real issues. I will fix those in the next revision.
Forwarding sashiko review in a reply format with my inline
comments below, for details of my view and doing discussions
via mails if needed.
> # review url: https://sashiko.dev/#/patchset/20260404163943.89278-5-sj@kernel.org
> # start of sashiko.dev inline review
> commit 5f8a4cfde3d93d0a4d4ac3d9a57f14f310c43e02
> Author: SeongJae Park <sj@kernel.org>
>
> Docs/admin-guide/mm/damon/usage: document fail_charge_{num,denom} files
>
> Update DAMON usage document for the DAMOS action failed regions quota charge
> ratio control sysfs files.
>
> > diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
> > index 534e1199cf091..3d6af6ce72d82 100644
> > --- a/Documentation/admin-guide/mm/damon/usage.rst
> > +++ b/Documentation/admin-guide/mm/damon/usage.rst
> [ ... ]
> > @@ -398,6 +401,13 @@ the background design of the feature and the name of the selectable algorithms.
> > Refer to :ref:`goals directory <sysfs_schemes_quota_goals>` for the goals
> > setup.
> >
> > +You can set the action-failed memory quota charging ratio by writing the
> > +numerator and the denominator for the ratio to ``fail_charge_num`` and
> > +`fail_charge_denom`` files, respectively. Reading those file will return the
>
> This isn't a bug, but fail_charge_denom has a single leading backtick and
> double trailing backticks.
>
> Additionally, should "Reading those file" be "Reading those files"?
Good catch! I will fix those in the next spin.
Thanks,
SJ
>
> > +current set values. Refer to :ref:`design
> > +<damon_design_damos_quotas_failed_memory_charging_ratio>` for more details of
> > +the ratio feature.
> > +
> > The time quota is internally transformed to a size quota. Between the
>
>
> # end of sashiko.dev inline review
> # review url: https://sashiko.dev/#/patchset/20260404163943.89278-5-sj@kernel.org
# hkml [1] generated a draft of this mail. You can regenerate
# this using below command:
#
# hkml patch sashiko_dev --for_forwarding \
# 20260404163943.89278-5-sj@kernel.org
#
# [1] https://github.com/sjp38/hackermail
^ permalink raw reply
* Re: (sashiko review) [RFC PATCH 3/9] Docs/mm/damon/design: document fail_charge_{num,denom}
From: SeongJae Park @ 2026-04-04 20:58 UTC (permalink / raw)
To: SeongJae Park; +Cc: damon, linux-doc, linux-kernel, linux-mm
In-Reply-To: <20260404163943.89278-4-sj@kernel.org>
Dropped individual Cc's except myself to reduce unnecessary traffic. I
initailly thought it would be good to keep Andrew in the Cc list, but even
Andrew may not really interested in each sashiko review for RFC patch, so I
dropped him from the list, too.
sashiko found issues. I will fix those in the next revision.
Forwarding sashiko review in a reply format with my inline
comments below, for details of my view and doing discussions
via mails if needed.
> # review url: https://sashiko.dev/#/patchset/20260404163943.89278-4-sj@kernel.org
> # start of sashiko.dev inline review
> commit bab641e86f0e9820b2ac0a7d4ae493d23c4c50f4
> Author: SeongJae Park <sj@kernel.org>
> Docs/mm/damon/design: document fail_charge_{num,denom}
>
> This commit updates the DAMON design document to explain the action-failed
> memory charging ratio. It provides an example of how to calculate the
> charged memory when an action fails for a portion of a region.
>
> > diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
> > index afc7d52bda2f7..01047e8431d17 100644
> > --- a/Documentation/mm/damon/design.rst
> > +++ b/Documentation/mm/damon/design.rst
> > @@ -565,6 +565,27 @@ interface <sysfs_interface>`, refer to :ref:`weights <sysfs_quotas>` part of
> > the documentation.
> >
> >
> > +.. _damon_design_damos_quotas_failed_memory_charging_ratio:
> > +
> > +Action-failed Memory Charging Ratio
> > +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > +
> > +DAMOS action to a given region can fail for sub subsets of the memory of the
>
> This isn't a bug, but should "sub subsets" just be "some subsets" or
> "subsets"?
Good eye. I will fix this in the next revision.
>
> > +region. For example, if the action is ``pageout`` and the region has some
> > +unreclaimable pages, applying the action to the pages will fail. The amount of
> > +system resource that is taken for such failed action applications is usually
> > +different from that for successful action applications. For such cases, users
> > +can set different charging ratio for such failed memory. The ratio can be
> > +specified using ``fail_charge_num`` and ``fail_charge_denom`` parameters. The
> > +two parameters represent the numerator and denominator of the ratio.
> > +
> > +For example, let's suppose a DAMOS action is applied to a region of 1 GiB size.
> > +The action is successfully applied to only 700 MiB of the region.
> > +``fail_charge_num`` and ``fail_charge_denom`` are set to ``1`` and ``1024``,
> > +respectively. Then only 700 MiB and 300 KiB of size (``700 MiB + 300 MiB * 1 /
> > +1024``) will be charged.
>
> Is this calculation accurate? Since 1 GiB is 1024 MiB, if 700 MiB are
> successfully applied, the remaining failed region would be 324 MiB rather
> than 300 MiB. Does the example intentionally use 1 GiB = 1000 MiB, or should
> the remaining portion be updated to 324 MiB?
Nice finding. I will fix this in the next revision.
Thanks,
SJ
>
>
> # end of sashiko.dev inline review
> # review url: https://sashiko.dev/#/patchset/20260404163943.89278-4-sj@kernel.org
# hkml [1] generated a draft of this mail. You can regenerate
# this using below command:
#
# hkml patch sashiko_dev --for_forwarding \
# 20260404163943.89278-4-sj@kernel.org
#
# [1] https://github.com/sjp38/hackermail
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox