On Sun, 19 Jan 2020 at 6:48 PM Valdis Klētnieks 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.