> On 30 Jul 2021, at 18:28, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > Tiberiu A Georgescu <tiberiu.georgescu@xxxxxxxxxxx> writes: > >> This patch follows up on a previous RFC: >> 20210714152426.216217-1-tiberiu.georgescu@xxxxxxxxxxx >> >> When a page allocated using the MAP_SHARED flag is swapped out, its pagemap >> entry is cleared. In many cases, there is no difference between swapped-out >> shared pages and newly allocated, non-dirty pages in the pagemap >> interface. > > What is the point? The reason why this patch is important has been discussed in my RFC patch and on this thread: https://lore.kernel.org/lkml/20210715201651.212134-1-peterx@xxxxxxxxxx/. The most relevant reply should be Ivan's: https://lore.kernel.org/lkml/CY4PR0201MB3460E372956C0E1B8D33F904E9E39@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/ In short, this swap information helps us enhance live migration in some cases. > > You say a shared swapped out page is the same as a clean shared page > and you are exactly correct. What is the point in knowing a shared > page was swapped out? What does is the gain? > What I meant was that shared swapped out pages and clean shared pages have their ptes identical pre-patch. I understand they are somewhat similar concepts when it comes to file shared pages, where swapping is done directly on the disk. Our case focuses on anonymous pages and shared pages with identical underlying behaviour (like pages allocated using memfd). These pages get cleared once the runtime is over, and the difference between allocated, but uninitialised pages, and dirty pages that have been swapped out is significant, as the former could still contain usable data. The post-patch pagemap entry now contains the swap type and offset for swapped out pages, regardless of whether the page is private or shared. This, by definition of the pagemap, should be the correct behaviour. > I tried to understand the point by looking at your numbers below > and everything I could see looked worse post patch. Indeed, the numbers are mostly bigger post-patch. It is a tradeoff between correctness and performance. However, the tradeoff is not inconvenient on sparse single accesses, and it can be made significantly faster by leveraging batching. In future work, the performance can be improved by leveraging a mechanism proposed by Peter Xu: Special PTEs: https://lore.kernel.org/lkml/20210715201422.211004-1-peterx@xxxxxxxxxx/ The main concern of the RFC was that the xarray check would slow down checking empty pages significantly. Thankfully, we can only see a small overhead when no allocated shared page is dirtied. > > Eric > Hope I was able to clarifiy a few things. Now, having laid out the context, please have another look at my proposed patch. Thank you, Tibi
