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 5711BC33CB1 for ; Sun, 19 Jan 2020 16:02:45 +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 A92F720679 for ; Sun, 19 Jan 2020 16:02:44 +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="jB/6L1Gy" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A92F720679 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 1itD1g-00015e-Qy; Sun, 19 Jan 2020 11:02:12 -0500 Received: from mail-lj1-x22f.google.com ([2a00:1450:4864:20::22f]) by shelob.surriel.com with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92.3) (envelope-from ) id 1itD1e-00015X-Jl for kernelnewbies@kernelnewbies.org; Sun, 19 Jan 2020 11:02:10 -0500 Received: by mail-lj1-x22f.google.com with SMTP id l2so31261009lja.6 for ; Sun, 19 Jan 2020 08:02:09 -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=H3wcoH8/wi/yh3zcMtv+QaH/t9SS79YHxDEXdZy8JCY=; b=jB/6L1Gyrh+NE+g0D5h5Qozfu1mt8S06r6mzMh6aHCmRU6fdBadFXIrUF20Hm+aNa9 /xPhmOBcDsCIZYqAP94f0C0e+lKUbUZEjCPdEXQ/co3AqFO+X3SFZVx+xiRdT6YT44Ma zXW989cGyrYz0yjUhIRsarRTGublzUMcCe+do3eVMfgq8pkOUZXxaSG2zmcj9jYN3HiN ga4i0es8p9KTHk3tBcp7h+9edSZKKXGfdiYn4fs0duuZEmre9DcT4rNkTlFKrJkcPhKv tyOqeXqijeLUTfOHodhItBaZMeoPXIHlFQ0DhR6rvqEDGSS56x+L7PONhuBzqlaztjlG B8sA== 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=H3wcoH8/wi/yh3zcMtv+QaH/t9SS79YHxDEXdZy8JCY=; b=TxIb75dclewh6mSdQKISgdt7e19hATKFTNc2bQz5qZ0Q7ln2dZJV0EOzOadQObTvyw vDXKGboNYU36hxN5LYfBD7F/hJgLSMOMWfrv4vb4pN5gUXlAyhc/gGI89uGiTolUtnlU oWHiOVHLYK/8RMO/1PF/i4lR+nlZw5ZUduSsG4HXsfy0FtHJ1YActlotmNQsp5FhY9/w GqAblRC/T1DrDn6wqtG7hFkQK+giLqBQKKTN4cLTMfYh+KiVZdZGFS5Zdo4L0k7QxOjv O2CAr6/WtDRK0xWF/tN9TYPzXSvmK3U9RqzUFPVJo+O1ckeKBtLJZA0Td/zF8Q/gBwE2 u3Rw== X-Gm-Message-State: APjAAAX7ijd+QX3pNExU4zs6uNfoEXiveUMrUo6uScm/YJLCFxSt5lo9 2eSN07GPaxyGuT9dodMQUdovF4FuZEFu3kxYBOo= X-Google-Smtp-Source: APXvYqyUx50fuFJId3XftTWy/Gc82sA5O1MN99xDYoWB7+fVusbQFyLXykX4NQUezeWTiEptsyx/spM2bhzHT5byEcU= X-Received: by 2002:a2e:7d01:: with SMTP id y1mr11448860ljc.100.1579449727584; Sun, 19 Jan 2020 08:02:07 -0800 (PST) MIME-Version: 1.0 References: <412530.1579360214@turing-police> <494631.1579432452@turing-police> <504953.1579439927@turing-police> In-Reply-To: <504953.1579439927@turing-police> From: Anupam Kapoor Date: Sun, 19 Jan 2020 21:31:56 +0530 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="===============7281105415459527414==" Errors-To: kernelnewbies-bounces@kernelnewbies.org --===============7281105415459527414== Content-Type: multipart/alternative; boundary="000000000000f411df059c804b7c" --000000000000f411df059c804b7c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, 19 Jan 2020 at 6:48 PM Valdis Kl=C4=93tnieks wrote: > On Sun, 19 Jan 2020 12:45:57 +0000, Anupam Kapoor said: > > > > Note that in this case, "naively" includes "not remembering to consid= er > > > 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 severa= l > 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... :) well sure, if you try to replicate everything that exists below libc, then there is little hope. however if your application=E2=80=99s data can be serialized/deserialized, = then i _suspect_ it might not be too much of work. for example, if i am maintaining l2 forwarding table entries then it might be possible to have, on an average fixed number of pages representing this cache... =E2=80=94 kind regards anupam > > -- In the beginning was the lambda, and the lambda was with Emacs, and Emacs was the lambda. --000000000000f411df059c804b7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, 19 Jan 2020 at 6:48 PM Valdis Kl=C4=93tnieks <valdis.kletnieks@vt.edu> wr= ote:
On Sun, 19 Jan 2020 12:45:57 += 0000, Anupam Kapoor said:

> > Note that in this case, "naively" includes "not re= membering to consider
> > that the page being unmapped may have contained data we'd rat= her
> > 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, incl= uding
code to marshal things like binary trees into a savable format, and more co= de
to read them back at a later time. Plus all the fun if the tree has hundred= s of thousands
or millions of entries, and how to deal with it if some parts of the tree h= ave 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 o= wn 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 diff= icult
10% takes the other 90% of the time... :)
well sure, if you try to replicate everything that= exists below libc, then there is little hope.

<= /div>
however if your application=E2=80=99s data can be se= rialized/deserialized, then i _suspect_ it might not be too much of work.= =C2=A0

for example, if i= am maintaining l2 forwarding table entries then it might be possible to ha= ve, on an average fixed number of pages representing this cache...

=E2=80=94
kind regards=C2=A0
anupam=C2=A0

--
In the beginning was the lambda, and the lambda was with = Emacs, and Emacs was the lambda.
--000000000000f411df059c804b7c-- --===============7281105415459527414== 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 --===============7281105415459527414==--