kernelnewbies.kernelnewbies.org archive mirror
 help / color / mirror / Atom feed
From: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
To: Anupam Kapoor <anupam.kapoor@gmail.com>
Cc: Sumit Kumar <sumit686215@gmail.com>,
	kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: transfer physical memory page to swap disk
Date: Sun, 19 Jan 2020 08:18:47 -0500	[thread overview]
Message-ID: <504953.1579439927@turing-police> (raw)
In-Reply-To: <CAEXHiZFyN1HzJnOXpCW0-UfGDpHgXSnv5gyaB-h7FJfdKp=8VQ@mail.gmail.com>


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

On Sun, 19 Jan 2020 12:45:57 +0000, Anupam Kapoor said:

> > Note that in this case, "naively" includes "not remembering to consider
> > that the page being unmapped may have contained data we'd rather
> > have kept by flushing the page to disk" :)
>
> but is it that bad ?
>
> before marking a page unmappable, the application has full control
> over what it wants to do with the data, and can choose to dump it
> to the appropriate destination.

Yes, but now you're getting into more code that has to be written, including
code to marshal things like binary trees into a savable format, and more code
to read them back at a later time. Plus all the fun if the tree has hundreds of thousands
or millions of entries, and how to deal with it if some parts of the tree have been
released and saved to disk, or if the 4K page contained members of several different
data structures - in other words, you probably just decided to write your own backing store,
garbage collector, and virtual object manager for your heap.

As I said - it's a naive approach that ends up following the 90/10 rule:
the easy 90% of it takes the first 90% of the time to code it, and the difficult
10% takes the other 90% of the time... :)

[-- 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:[~2020-01-19 13:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15 12:31 transfer physical memory page to swap disk Sumit Kumar
2020-01-15 12:42 ` aleix sanchis ramírez
2020-01-15 12:53 ` Anupam Kapoor
2020-01-18 15:10   ` Valdis Klētnieks
2020-01-19 10:01     ` Sumit Kumar
2020-01-19 10:55     ` Anupam Kapoor
2020-01-19 11:14       ` Valdis Klētnieks
2020-01-19 12:45         ` Anupam Kapoor
2020-01-19 13:18           ` Valdis Klētnieks [this message]
2020-01-19 16:01             ` Anupam Kapoor
2020-01-19 16:59 ` Bernd Petrovitsch

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=504953.1579439927@turing-police \
    --to=valdis.kletnieks@vt.edu \
    --cc=anupam.kapoor@gmail.com \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=sumit686215@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).