Take a look to this: https://www.youtube.com/watch?v=6S9DDTFyjrY I attended a presentation with the same name in the last Kernel Recipes and was very clarifying. Cheers! On Fri, Oct 6, 2017 at 8:29 PM, Damian Tometzki <damian.tometzki@xxxxxxxxxx> wrote: > 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@xxxxxx: >> 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@xxxxxxxxxxxxxxxxx >> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > > > _______________________________________________ > Kernelnewbies mailing list > Kernelnewbies@xxxxxxxxxxxxxxxxx > https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies -- Ricardo Ribalda _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
