transfer physical memory page to swap disk
anupam.kapoor at gmail.com
Sun Jan 19 11:01:56 EST 2020
On Sun, 19 Jan 2020 at 6:48 PM Valdis Klētnieks <valdis.kletnieks at vt.edu>
> 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,
> code to marshal things like binary trees into a savable format, and more
> 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
> 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
> 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
In the beginning was the lambda, and the lambda was with Emacs, and Emacs
was the lambda.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Kernelnewbies