help in the MM Area of the Linux Kernel

[Damian Tometzki]

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