>> 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ētnieks <valdis.kletni...@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 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" :) >
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies