Kernel Newbies archive on lore.kernel.org
 help / color / Atom feed
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
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 --]

<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace">&gt;&gt; but if _all_ that is required is randomly unmapping some marked<br>&gt;&gt; application pages, _that_ can be naively &#39;done&#39; by the application<br>&gt;&gt; itself :)<br><br>&gt; Note that in this case, &quot;naively&quot; includes &quot;not remembering to consider<br>&gt; that the page being unmapped may have contained data we&#39;d rather<br>&gt; have kept by flushing the page to disk&quot; :)<br clear="all"></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">but is it that bad ? <br><br>before marking a page unmappable, the application has full control<br>over what it wants to do with the data, and can choose to dump it<br>to the appropriate destination.<br><br>or if enough information is available, the unmapper thread can itself<br>play that role.<br><br>thinking some more about it, application has full control over the<br>unmap/resurrect behavior. though latter might not be as<br>transparent...<br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">--</div><div class="gmail_default" style="font-family:monospace,monospace">kind regards</div><div class="gmail_default" style="font-family:monospace,monospace">anupam</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><font face="monospace, monospace">In the beginning was the lambda, and the lambda was with Emacs, and Emacs was the lambda. </font></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 19, 2020 at 11:14 AM Valdis Klētnieks &lt;<a href="mailto:valdis.kletnieks@vt.edu">valdis.kletnieks@vt.edu</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 19 Jan 2020 10:55:44 +0000, Anupam Kapoor said:<br>
<br>
&gt; but if _all_ that is required is randomly unmapping some marked<br>
&gt; application pages, _that_ can be naively &#39;done&#39; by the application<br>
&gt; itself :)<br>
<br>
Note that in this case, &quot;naively&quot; includes &quot;not remembering to consider<br>
that the page being unmapped may have contained data we&#39;d rather<br>
have kept by flushing the page to disk&quot; :)<br>
</blockquote></div>

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

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

  reply index

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-15 12:31 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 publically 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

Kernel Newbies archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kernelnewbies/0 kernelnewbies/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 kernelnewbies kernelnewbies/ https://lore.kernel.org/kernelnewbies \
		kernelnewbies@kernelnewbies.org
	public-inbox-index kernelnewbies

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernelnewbies.kernelnewbies


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git