From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3B51EC33CB1 for ; Sun, 19 Jan 2020 12:50:59 +0000 (UTC) Received: from shelob.surriel.com (shelob.surriel.com [96.67.55.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9097B2072B for ; Sun, 19 Jan 2020 12:50:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="BedwFK6D" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9097B2072B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernelnewbies-bounces@kernelnewbies.org Received: from localhost ([::1] helo=shelob.surriel.com) by shelob.surriel.com with esmtp (Exim 4.92.3) (envelope-from ) id 1itA2D-0006LE-Io; Sun, 19 Jan 2020 07:50:33 -0500 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1itA2B-0006L2-SO for kernelnewbies@kernelnewbies.org; Sun, 19 Jan 2020 07:50:31 -0500 Received: by mail-lj1-x236.google.com with SMTP id j1so31023201lja.2 for ; Sun, 19 Jan 2020 04:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lw1W0uuzCZn1M0LOdRDBF7cYSkCw5MfiFpGFy79/Zhs=; b=BedwFK6DL4ntOwmvOA2tMnENFYBhAG6WcN+XB2xZ7d2m/lUwWn7tp6JkTogNGJjN1p au6Qf/+L0F4WU5DfoygV5wONfLxxEPX9by2mf29HfQ2UQYTeqyqtU7hC7rW0F6AiTLlz 8TlgfAZQENxHAcKhSOmDiMDJQoIwK3BBnNBlsedoZJdHRPr0Ac1cxh70jdIOSOD61mwz KcKK11s7Nu58EDB5vyaoY5/7pUMDRQeJ2g+ULrsLb0murS+F89uhq782ByQ3wRADJCYU UtoKSZdcQFP67S262nJpfXNI0Uv4p8sQXO//ySK2xK8yYsdx09tuOUkBrB0iOCQmd7RY Kurw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lw1W0uuzCZn1M0LOdRDBF7cYSkCw5MfiFpGFy79/Zhs=; b=qmqGNDmpRQNoSpgHuzPkxK39EDkVyZvRzwWkpHhPqMQRfQc4eYL7wnm05q8pNfXiS9 r07As1cEicJoLfu9YQ9NqlIJlqrmLZdjtwKBInPLptjr1OuUR4CWcqdtLa+jI5182xfQ 3J953y7KeaToMNF8UPbL94twZAO+WODH3Gqlauy/yT60GlBrcJ3ExhRLyyRy79prn6e2 rl/zNYL/7FXXsOX+YG4Jjkb0VZp6bicDb+afqrOssUBKqjSEjXKjXXi/ddePQ+b2KyzC YHVijoA9Po0m1u+9e0dCfQwYzFcLrNLe3mgMYPzT42Kw/Ofbxqk4RxLsjJPYqEmdLnx2 +x9Q== X-Gm-Message-State: APjAAAXYOpAkczrUBOWH8gNLrWWbMjO6RTFN/w0KxIlhvIKTEeGaXnkP Ohz+RoN6gLDCovbIdK+vYTkTYt7qAgt0nDDkxFk= X-Google-Smtp-Source: APXvYqyF+KlxQyVc+Qy5BMzm5i/pTW+kfItkII96F2kLbed6KPijZCX+4O/xUKldJJpIBN/lq7G1OtTbKV/Nc8CyoeA= X-Received: by 2002:a2e:81c7:: with SMTP id s7mr11160569ljg.3.1579438168536; Sun, 19 Jan 2020 04:49:28 -0800 (PST) MIME-Version: 1.0 References: <412530.1579360214@turing-police> <494631.1579432452@turing-police> In-Reply-To: <494631.1579432452@turing-police> From: Anupam Kapoor Date: Sun, 19 Jan 2020 12:45:57 +0000 Message-ID: Subject: Re: transfer physical memory page to swap disk To: =?UTF-8?Q?Valdis_Kl=C4=93tnieks?= Cc: Sumit Kumar , kernelnewbies X-BeenThere: kernelnewbies@kernelnewbies.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Learn about the Linux kernel List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============4896414437541962206==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============4896414437541962206== Content-Type: multipart/alternative; boundary="000000000000faf8a0059c7d9a67" --000000000000faf8a0059c7d9a67 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >> 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=C4=93tnieks 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" :) > --000000000000faf8a0059c7d9a67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>> but if _all_ that is required is randomly unmapping s= ome marked
>> application pages, _that_ can be naively 'done&#= 39; 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
&= gt; have kept by flushing the page to disk" :)
=

=
but is it that bad ?=C2=A0

before marking a page unmappable, the a= pplication has full control
over what it wants to do with the data, and = can choose to dump it
to the appropriate destination.

or if enoug= h information is available, the unmapper thread can itself
play that rol= e.

thinking some more about it, application has full control over th= e
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=C4=93tnieks <= ;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 applica= tion
> 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" :)
--000000000000faf8a0059c7d9a67-- --===============4896414437541962206== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies --===============4896414437541962206==--