kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: Akash Sarda <sardaakash7@gmail.com>
Cc: kernelnewbies@kernelnewbies.org
Subject: Re: Just joined
Date: Tue, 19 Nov 2019 15:20:07 -0500	[thread overview]
Message-ID: <138322.1574194807@turing-police> (raw)
In-Reply-To: <CALqSAquqcg+VfTiiW9N4yiydKvpkYyKzpDesBLT1RQef69Jx-A@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 1910 bytes --]

On Tue, 19 Nov 2019 17:03:37 +0530, Akash Sarda said:
> Hi,
>
> My name is Akash, and I want to start with OS development..
> I am interested in memory management, and would like to know if anyone
> has a newbie project in their mind..

Unfortunately, there's probably not much good newbie work in memory management,
because a whole lot of experts have already gone over it and make it work
reasonably well on *literally* everything from light bulbs to supercomputers.

I'm not saying there's nothing in there for a newbie to do. There's probably
still tons of minor enhancements that can be done, but they're going to require
that you actually understand the code at a fairly deep level. For example,
here's a recent commit:

commit abc04c84ae77fdbce2c42c52e4059d327e54c7ab
Author: Minchan Kim <minchan@google.com>
Date:   Wed Nov 6 16:06:48 2019 +1100

    mm/page_io.c: annotate refault stalls from swap_readpage

    If a block device supports rw_page operation, it doesn't submit bios so
    the annotation in submit_bio() for refault stall doesn't work.  It happens
    with zram in android, especially swap read path which could consume CPU
    cycle for decompress.  It is also a problem for zswap which uses
    frontswap.

    Annotate swap_readpage() to account the synchronous IO overhead to prevent
    underreport memory pressure.

The description of what was changed and why runs to just under 500 characters,
while the actual change is well under 200.

I'm assuming you've already cloned either Linus's git tree or one or more of
the development trees.   If so, you can do a 'git log mm/' and see what work
has been recently done, so you know what sort of learning curve you're
going to have.

You definitely need to read the various files under Documentation/process
and you probably should go read this as well:

https://lists.kernelnewbies.org/pipermail/kernelnewbies/2017-April/017765.html

[-- Attachment #1.2: Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 170 bytes --]

_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies

  reply	other threads:[~2019-11-19 20:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-19 11:33 Just joined Akash Sarda
2019-11-19 20:20 ` Valdis Klētnieks [this message]
2019-11-20  4:48   ` Akash Sarda
2019-11-20  6:43     ` Lukas Bulwahn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=138322.1574194807@turing-police \
    --to=valdis.kletnieks@vt.edu \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=sardaakash7@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).