Re: [PATCH 0/2] mm/compaction: stop repeating failed async compaction on every THP fault

[Qiliang Yuan]

Hi Lorenzo,

Thanks for your review. I would like to respond to your points,
quoting your mail below.

> NAK.

I understand your right to NAK as a maintainer. I am not asking
you to withdraw it automatically. I am clarifying the facts.

> This series is buggy, and has triggered my AI detection script.

If there are real bugs, I will fix them. But an AI-detection
script finding bugs is not proof that the code was generated by
an LLM. Automated review tools commonly find bugs in complex
kernel code. The dhm series has been in development for a long
time and has gone through several versions; the dynamic core
isolation design touches many kernel subsystems, so bugs found
by automated review are not surprising.

> It is kernel policy that you must disclose this with an
> Assisted-by tag like:
>
> Assisted-by: LLM

I agree with this policy. I did not use an LLM to generate the
patch code, but I used GLM to help run test data. I will disclose
the GLM use; if an Assisted-by tag is required, I will add it.
If I ever use an LLM to generate code, I will disclose that as
well.

> It is also kernel policy that you must fully understand and take
> responsibility for every patch that you send.

I understand and take full responsibility for every patch I send.

> The script noted:
>
> - Output rate: since 09-28 he has sent KVM SMM CR3/Hyper-V,
>   ext4+jbd2+quota "shrinker scan budget accounting" (the same fix
>   applied to three shrinkers; jbd2 went v1->v5 in 3 days and v1->v3
>   in 3 hours), blk-mq SRCU tag sets, a blk-mq sync-run, ublk x2,
>   a 4-patch bpf-next verifier rework, mm/migrate move_pages (v2
>   sent 10h after v1) and this series. That is ~9 unrelated deep
>   areas in 4 days from someone with 4 commits.

I respect this guidance. I do not often have time to send
patches to the community; work keeps me busy. I am not spamming.
I only recently had time to send work that has been in progress
for months:

- The dhm series has been developed for a long time and has gone
  through several versions. The dynamic core isolation design
  touches many kernel subsystems, so bugs found by automated
  review are common.
- The bpf series is something I started while optimizing bpf
  earlier but did not have time to finish. Similar work was
  attempted in 2019, it is complex and not easy to write, and
  this has been pending for more than 9 months.
- The KVM SMM CR3/Hyper-V fix comes from a real problem I hit
  using Win11 WSL2 + virt-manager. I fixed it internally a long
  time ago but did not push it upstream. I only sent it after
  finding Win11 still had not fixed it.
- I have been working on storage for the past few months. The
  ext4+jbd2+quota changes are the same logic in three places;
  once one was found, fixing the others followed naturally, as
  documented in kernel docs. The v1 of those three small patches
  already received Reviewed-by tags; I only made small changes
  and added test data after a reviewer raised a different
  opinion.
- blk-mq, ublk, mm/migrate, and mm/compaction are performance
  issues I found while working on heterogeneous KV-cache AI
  optimization over the past months, using perf, ftrace, bpf,
  etc.

> Given you sent your first mail on 21st September and have since
> been spamming complicated series across multiple different
> domains, I'm absolutely not confident that you have any
> understanding of this.

I am not spamming. I only recently had time to send work that
has been in progress for months. The areas are not unrelated
from my side: they come from storage, virtualization, BPF, and
heterogeneous KV-cache AI optimization work.

> It also noted that you had a previous email, realwujing@xxxxxxxxx,
> which you have silent switched from, which also bore the
> hallmarks of AI slop.

realwujing@xxxxxxxxx was an old personal email address. I no
longer want to use it, so I switched to odys.yuan@xxxxxxxxx.
There was no intent to hide anything; it is simply an email
change.

> It also found several glaring flaws with your series, so it's
> clearly not upstreamable.

If there are concrete flaws, please point them out, or I will go
through the Sashiko findings one by one and fix them.

Thanks,
Qiliang