Message-ID: <9ab2c883-9707-4c30-9922-c2ff83d35677@arm.com>
Date: Sun, 9 Nov 2025 14:57:58 +0530
From: Dev Jain <dev.jain@....com>
To: Swaraj Gaikwad <swarajgaikwad1925@...il.com>
Cc: akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org
Subject: Re: Guidance on contributing to MM subsystem


On 09/11/25 7:44 pm, Swaraj Gaikwad wrote:
> Hi Dev,
> Thank you so much for your reply and for sharing your experience.
> I do have some basic understanding of how parts of the MM subsystem work,
> but I’m still struggling with how to find meaningful issues or tasks to work
> on. For example, I’ve been trying to explore various parts of the code and
> read through documentation to get a better grasp of how things fit together.
>
> In other open-source projects, like on GitHub, there’s usually an “Issues”
> section where contributors can easily find bugs or tasks to work on. In the
> kernel, should I mainly focus on exploring TODOs, adding selftests, or
> improving documentation (especially for new or less-documented parts)? I
> also believe branches like mm-unstable and mm-new might have ongoing issues
> or regressions, but how do developers usually find or detect them? Would
> simply building these branches expose such problems through compiler errors,
> or should I try building with different configurations (for example, using
> defconfig and other configs) to uncover potential issues?

Yes this may be an option, to pick up mm-new and build it with
various configurations which are not extensively tested, and stress testing
with mm-selftests/mm-tests by Mel Gorman, etc. I had my first bug report
by just randomly testing CONFIG_LPA2 on arm64:

https://lore.kernel.org/all/20240415094003.1812018-1-anshuman.khandual@arm.com/

>
> Even though I’m beginning to understand how different parts of the subsystem
> interact, I’m not sure how developers usually identify new bugs or feature
> ideas to work on. Once I understand the code flow better, how can I
> effectively find such issues or areas where help is actually needed?

I would say to not pressurize yourself to find tasks, but focussing on
learning the code. Try to review patches - that will increase your
understanding of the code, and it will make you sit in the shoes
of the poster and think "what made them think of this work?". Leaving
aside very big functionality changes, most of the patches, in my experience,
are found by extreme understanding of the code and while reading it,
having an aha moment of "this looks stupid", "this is a bug" or
"surely there is a better way of doing this".

I'll give some examples.

https://lore.kernel.org/all/20251017160251.96717-1-dev.jain@arm.com/

I figured this out when reading mprotect code and observed that we are
doing an unconditional TLB flush (via mmu gather) for arm64 - pte_needs_flush()
was not implemented there. It is obvious (if you know about pte protections)
that we don't need to do that for a transition from PROT_NONE to any other.

https://lore.kernel.org/all/20250610035043.75448-1-dev.jain@arm.com/
https://lore.kernel.org/all/20250718090244.21092-1-dev.jain@arm.com/

On arm64, ptep_get() becomes costly due to collection of a/d bits for cont mappings;
I literally went around the codebase and checked whether we can batch process ptes
to avoid this cost.

https://lore.kernel.org/all/20250908075028.38431-1-dev.jain@arm.com/

I observed that khugepaged is operating only on writable regions. This didn't make
any sense to me - I scanned the history and couldn't prove that this is of any
use, hence posted on the list, and the community agreed (and the performance numbers
agreed too, as described in the cover letter).

One more interesting example -
https://lore.kernel.org/all/13945f06-f862-4f80-904a-f2a4ccff3e4b@redhat.com/

While reviewing an unrelated patch, David Hildenbrand reads the code and spots a problem
with the existing code, which was brought in by my patch, and I had to fix it in this:
https://lore.kernel.org/all/20251028063952.90313-1-dev.jain@arm.com/


As you can see, we "observed" all these things. The probability of making an observation
is directly proportional to the knowledge of the codebase (as is true with any other
skill). Which leads me to the conclusion - focussing on finding a task may be counter-productive.
Reviewing patches will force you to read the code and find potential problems with it.

>
> Thanks again for your time and guidance!
>
> Best regards,
> Swaraj Gaikwad

Powered by blists - more mailing lists