help in the MM Area of the Linux Kernel

[Ricardo Ribalda Delgado]

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 at icloud.com> 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 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
>
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies



-- 
Ricardo Ribalda