Re: [PATCH 0/1] pagemap: swap location for shared pages

[Tiberiu Georgescu]

> 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