From: Anupam Kapoor <anupam.kapoor@gmail.com>
To: "Valdis Klētnieks" <valdis.kletnieks@vt.edu>
Cc: Sumit Kumar <sumit686215@gmail.com>,
kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: transfer physical memory page to swap disk
Date: Sun, 19 Jan 2020 12:45:57 +0000 [thread overview]
Message-ID: <CAEXHiZFyN1HzJnOXpCW0-UfGDpHgXSnv5gyaB-h7FJfdKp=8VQ@mail.gmail.com> (raw)
In-Reply-To: <494631.1579432452@turing-police>
[-- Attachment #1.1: Type: text/plain, Size: 1398 bytes --]
>> but if _all_ that is required is randomly unmapping some marked
>> application pages, _that_ can be naively 'done' by the application
>> itself :)
> 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.
or if enough information is available, the unmapper thread can itself
play that role.
thinking some more about it, application has full control over the
unmap/resurrect behavior. though latter might not be as
transparent...
--
kind regards
anupam
In the beginning was the lambda, and the lambda was with Emacs, and Emacs
was the lambda.
On Sun, Jan 19, 2020 at 11:14 AM Valdis Klētnieks <valdis.kletnieks@vt.edu>
wrote:
> On Sun, 19 Jan 2020 10:55:44 +0000, Anupam Kapoor said:
>
> > but if _all_ that is required is randomly unmapping some marked
> > application pages, _that_ can be naively 'done' by the application
> > itself :)
>
> 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" :)
>
[-- Attachment #1.2: Type: text/html, Size: 2593 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
next prev parent reply other threads:[~2020-01-19 12:50 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 [this message]
2020-01-19 13:18 ` Valdis Klētnieks
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='CAEXHiZFyN1HzJnOXpCW0-UfGDpHgXSnv5gyaB-h7FJfdKp=8VQ@mail.gmail.com' \
--to=anupam.kapoor@gmail.com \
--cc=kernelnewbies@kernelnewbies.org \
--cc=sumit686215@gmail.com \
--cc=valdis.kletnieks@vt.edu \
/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).