From mboxrd@z Thu Jan  1 00:00:00 1970
From: damian.tometzki@icloud.com (Damian Tometzki)
Date: Fri, 06 Oct 2017 20:29:29 +0200
Subject: help in the MM Area of the Linux Kernel
In-Reply-To: <5997.1507307670@turing-police.cc.vt.edu>
References: <1507220048.1800.7.camel@icloud.com>
	<5997.1507307670@turing-police.cc.vt.edu>
Message-ID: <1507314569.1800.9.camel@icloud.com>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

Hello Valdis,

thank you you for you reply. I'work for a big company as SAP partner
and i responsible for SAP HANA and the infrastucture.?

My personal intrest is the memory managment. My impression was the same
as you answerded.?

As you said i will try to figure out what the mm code is doing and try
to find out what can we do better.?


Damian



Am Freitag, den 06.10.2017, 12:34 -0400 schrieb
valdis.kletnieks at vt.edu:
> On Thu, 05 Oct 2017 18:14:08 +0200, Damian Tometzki said:
> 
> > 
> > i'am intrested in helping and Bug Fixing in the mm area of the
> > linux
> > kernel.?
> > 
> > For driver development is it clear check in the staging area the
> > TODO's.?
> > 
> > And what is the process for other areas of the kernel for example
> > mm
> > (Memory management X86) ??
> Rule 1 of kernel hacking:??Not every mechanic gets to work on Formula
> 1
> engines.
> 
> For mm, you'll probably need to show some expertise in other kernel
> areas,
> *plus* have a deep understanding of memory management theory. That
> code has
> already been worked over by multiple professionals, which means
> pretty much all
> the easy stuff has already been done.
> 
> Oh, and you're probably going to also need knowledge of the kernel
> instrumentation - perf, tracepoints, and friends.
> 
> If you manage to find an actual bug in that code, it is most likely
> going to be
> some weird corner case, and *much* MM clue will be required to fix it
> without
> breaking some *other* more common corner case.??Remember that the
> same code has
> to Do The Right Thing on everything from an embedded system with 32M
> of RAM and
> only one major process running, to large mainframe class boxes with a
> terabyte
> of RAM, a large Oracle instance, and several hundred Apache / Tomcat
> / etc
> processes flickering in and out of existence, to multi-terabyte
> systems running
> HPC (where the use of RDMA over Infiniband by things like MPI creates
> challenges due to a *lot* of locked pages...)
> 
> Your best bet???Find a replicable corner case (this may require
> access to a
> variety of systems), create a test-case that can cause the corner
> case on
> demand.??Figure out what the mm code is doing, and how it could do it
> better.
> Write a patch, test, and then double-check on other systems that you
> didn't
> cause a regression.??Submit the patch.
> 
> Good luck. :)
> 
> 
> 
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies