transfer physical memory page to swap disk

[Anupam Kapoor]

On Sun, 19 Jan 2020 at 6:48 PM Valdis Klētnieks <valdis.kletnieks at vt.edu>
wrote:

> 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... :)


well sure, if you try to replicate everything that exists below libc, then
there is little hope.

however if your application’s 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...

—
kind regards
anupam

>
> --
In the beginning was the lambda, and the lambda was with Emacs, and Emacs
was the lambda.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20200119/f0f09ed4/attachment.html>