Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <2ddfad15-394c-241f-b120-5b297ed5356f@oracle.com>
Date:   Thu, 30 Jun 2022 09:39:24 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.1
Subject: Re: [PATCH v2 0/9] Add support for shared PTEs across processes
Content-Language: en-US
To:     Mark Hemment <markhemm@googlemail.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>,
        aneesh.kumar@linux.ibm.com, arnd@arndb.de, 21cnbao@gmail.com,
        corbet@lwn.net, dave.hansen@linux.intel.com, david@redhat.com,
        ebiederm@xmission.com, hagen@jauu.net, jack@suse.cz,
        Kees Cook <keescook@chromium.org>, kirill@shutemov.name,
        kucharsk@gmail.com, linkinjeon@kernel.org,
        linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        Linux-MM <linux-mm@kvack.org>, longpeng2@huawei.com,
        luto@kernel.org, pcc@google.com, rppt@kernel.org,
        sieberf@amazon.com, sjpark@amazon.de,
        Suren Baghdasaryan <surenb@google.com>, tst@schoebel-theuer.de,
        yzaikin@google.com
References: <cover.1656531090.git.khalid.aziz@oracle.com>
 <CANe_+Uj6RXw_X5Bv9_UkD_ngA_7haz3rqmbd2FAGzP1uHsxAfA@mail.gmail.com>
From:   Khalid Aziz <khalid.aziz@oracle.com>
In-Reply-To: <CANe_+Uj6RXw_X5Bv9_UkD_ngA_7haz3rqmbd2FAGzP1uHsxAfA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K0E0NmVVSWV6ZS91U2hZbm54clJGNXBEZk5QNWJZVnFIMDRTQzExYm45WGVz?=
 =?utf-8?B?eHRyRWhKY3pFR3RiWDN6NXZHZkFTK3ZzMXhKRTc2VnNTR3pXTC9na05ENUQ4?=
 =?utf-8?B?cTIzMHVsekhDOFM2MThGRjhmQzgwZlFnUkIxaTRqNVlackNnR1lOb3VCbllL?=
 =?utf-8?B?QkZoT2lDQUtEQVRsVUUvNmJacEc3UEpabTNubURrNVQreGE1QnAzbHpVYS9m?=
 =?utf-8?B?ZjlxeGpxa2dCMWp1Vkw4WlBWRkU0Q21tVWp4WE93eHdjWEQ0VW9pRTB5STNy?=
 =?utf-8?B?ck9NeG1zRjVDelN4OHhqVG5WZXJUNVVpMlVSamRXa2xMbXdNRVZ5SGgwVzVj?=
 =?utf-8?B?anBuNElBc1RQcm1Nd2UrTlhTd0lwNWJxTlp2UlRsTDJWYmQrKzVLcmdYam92?=
 =?utf-8?B?dFRRcmdQZHJwVVh1WVNFZ0xiWUdDUEZaSVZuYTMzaHNQYmhUWndBV2pIQjEw?=
 =?utf-8?B?dlE3cmVCVU1DMmpmYkd3SFFWTHRyUnQrQkpudTNUSzgvTmpVUWZOZEh1TnN5?=
 =?utf-8?B?V2JKSVAxTDFnUDBVZndRbkVNMVFyYlE2WmNWUXNONzI1MHlvRDVXR1E4enRE?=
 =?utf-8?B?UkpqdThNSFNJY2huM2dZbkM4RFg1QzJSNGg3bGd2MWJ0VkhMakVCRncvOFlL?=
 =?utf-8?B?Yndyd2ZjVnFLTDVkWXl3d1phRzRlSFlRQWI1ZUF5Um9LYUFzWHdHTm5ML09Y?=
 =?utf-8?B?ZGRiNWVaa1lIUkp0TFE4MVU5MmNxSEJBTEpmS3NTNGZuTUdzN2FubDMyQmRY?=
 =?utf-8?B?YnB5TkxtOEgyY09FMFVhTkhEUDdaWHU5WUZtYUJOdDhzeDBzSTdCMUxRZ3gx?=
 =?utf-8?B?Unc3UEZoU0xHdlhUdnU0ejZEc2MySDl4TTFXWjY1TVdudWNwanEzd0QyUjRn?=
 =?utf-8?B?RHhiZEtMNWpLa2FRNThwZEVLZy9mS3poeG5HUGEreXV4U21iMnBxUkR0bGhZ?=
 =?utf-8?B?aWEyKzBUTTlWbUFQKzBDZUQxeW1zcFVjS2pVRVJMUGk3K095YkYzTUhnWmdr?=
 =?utf-8?B?T2RObzJSSW9XS2h6Zlo2cjUreDBYa0htaDBwejVpUit3SDQweXVFeGdoNVdK?=
 =?utf-8?B?V09TRi96SnJhZHNFaTVKMDloNWVKTWdDQnpLSk42czFyK3d2ZFpCT0hhS3dT?=
 =?utf-8?B?MlVaaE9wZVhQeTk0Z0s3UTBiS3ZxeTBIWldHM3BHVWpJcDF6aWk4QXE0bE1a?=
 =?utf-8?B?eGtxVGx0d0ovTVJnelhmVzg4emZ0ckpPVVpWSkFleVVhU0Y0QUx2Vk1TTWR1?=
 =?utf-8?B?dUd2aEZWK2RlNGpRWGZFbXkxZjFtaU1mbjJKNSsyZ1d5ZnRJRGFuY3BHWEZa?=
 =?utf-8?B?UVVpV1FheU93a2lUbTYrUHFBNCt4RlltR09vaWJwenAyRit6bHVBOHlLcWJW?=
 =?utf-8?B?R05mWlRMWlFYWEs0aHI0a0pwZktVRWNTcTdNTWFWeURyQVN5UThzYXNxWEtT?=
 =?utf-8?B?VXh6MUppVHY5alljdUlPdlozZnErWmwrNktkNnUxV05tc3ZlOWlsRVJGV1R1?=
 =?utf-8?B?WUYwWHRVa2VZZE1UTmF0Q2FsME1XbHFmTkdkYlNvcStIWHVhQWRMM2xKWUp2?=
 =?utf-8?B?SURWRDFMaktvaExROXNWRFhycFZIYlozN2dxZG82WXVWNENFU0JpeUwzb0VC?=
 =?utf-8?B?My82L3FXak54OG0vNmZ2eldvUGU1dUd1SmJMQzE0WlJrRE5neFdrb0h1Ymtj?=
 =?utf-8?B?T1pxcUpBRXB0bDNqVmtXY0JOWjdKcDl1QzlGRi82bzVjUVRObGZxWVlKNitl?=
 =?utf-8?B?UDk0VjRRNnA2di85VXdhcmU4THBwekJmZWdsYkttREcrY2d5eUxoQmpzUWNx?=
 =?utf-8?B?NFlsTTN3blpaVllSOGgvOTZ3eFNHOWhnLzlZNWVHWXVHUWdBMWJOYjlGRzQz?=
 =?utf-8?B?clNtNW45ZS9GdHZCWWFpQm9zanpNc2E2TDkxNVNoRllvWXNLaWJWekU4dUl4?=
 =?utf-8?B?cnR2WWliR2pjdW5pOUU1R2RETjRmbUw2eGo3SkcvaDJQdi9vUVhJTFhqSHFT?=
 =?utf-8?B?dEFkSWNGcndOalExOCtPQWhLN3BaWklkN2s3bCtjdWVTM3ZoemFiVU0zUHdO?=
 =?utf-8?B?NE0yVUlBamIwUGhHbnB2SElDbktnMm1VMGNRMFQ0amJKQzM1WHRacUh2Vm1I?=
 =?utf-8?B?L1c1dGpPVlFzbk05OCsyeWpVQkNSOE5GbFlXdkh3Q1JyWFptSmhSQUtFdlBr?=
 =?utf-8?B?VHE4LzQ1ZVFGZUZweEZwL0pNYy9ZWThaMUlWNXNYV1EyWS9qT3ZJL0JpV0Nr?=
 =?utf-8?B?RHBJb05nQmN5ZWNBYWVjdFRocWdRPT0=?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e16e1c65-6fe2-4033-4a2d-08da5aaeb7fc
X-MS-Exchange-CrossTenant-AuthSource: BN8PR10MB3220.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Jun 2022 15:39:28.6264
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: hUNxmn5iH3+zxersqG21rWHoDjx3/SPnrdYB0PLjeyUaKVg84HrCsq0VSCd4X1EricvE81hc5PSGh/yTNZSPhw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR10MB4737
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.517,18.0.883
 definitions=2022-06-30_11:2022-06-28,2022-06-30 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 bulkscore=0 spamscore=0
 malwarescore=0 suspectscore=0 mlxlogscore=999 adultscore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2204290000
 definitions=main-2206300062
X-Proofpoint-ORIG-GUID: lRM3StzGVOq7XhVTcCdaJfsVlcq83fcC
X-Proofpoint-GUID: lRM3StzGVOq7XhVTcCdaJfsVlcq83fcC
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE
        autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 6/30/22 05:57, Mark Hemment wrote:
> Hi Khalid,
> 
> On Wed, 29 Jun 2022 at 23:54, Khalid Aziz <khalid.aziz@oracle.com> wrote:
>>
>>
>> Memory pages shared between processes require a page table entry
>> (PTE) for each process. Each of these PTE consumes consume some of
>> the memory and as long as number of mappings being maintained is
>> small enough, this space consumed by page tables is not
>> objectionable. When very few memory pages are shared between
>> processes, the number of page table entries (PTEs) to maintain is
>> mostly constrained by the number of pages of memory on the system.
>> As the number of shared pages and the number of times pages are
>> shared goes up, amount of memory consumed by page tables starts to
>> become significant. This issue does not apply to threads. Any number
>> of threads can share the same pages inside a process while sharing
>> the same PTEs. Extending this same model to sharing pages across
>> processes can eliminate this issue for sharing across processes as
>> well.
>>
>> Some of the field deployments commonly see memory pages shared
>> across 1000s of processes. On x86_64, each page requires a PTE that
>> is only 8 bytes long which is very small compared to the 4K page
>> size. When 2000 processes map the same page in their address space,
>> each one of them requires 8 bytes for its PTE and together that adds
>> up to 8K of memory just to hold the PTEs for one 4K page. On a
>> database server with 300GB SGA, a system crash was seen with
>> out-of-memory condition when 1500+ clients tried to share this SGA
>> even though the system had 512GB of memory. On this server, in the
>> worst case scenario of all 1500 processes mapping every page from
>> SGA would have required 878GB+ for just the PTEs. If these PTEs
>> could be shared, amount of memory saved is very significant.
>>
>> This patch series implements a mechanism in kernel to allow
>> userspace processes to opt into sharing PTEs. It adds a new
>> in-memory filesystem - msharefs. A file created on msharefs creates
>> a new shared region where all processes sharing that region will
>> share the PTEs as well. A process can create a new file on msharefs
>> and then mmap it which assigns a starting address and size to this
>> mshare'd region. Another process that has the right permission to
>> open the file on msharefs can then mmap this file in its address
>> space at same virtual address and size and share this region through
>> shared PTEs. An unlink() on the file marks the mshare'd region for
>> deletion once there are no more users of the region. When the mshare
>> region is deleted, all the pages used by the region are freed.
> 
>    Noting the flexibility of 'mshare' has been reduced from v1.  The
> earlier version allowed msharing of named mappings, while this patch
> is only for anonymous mappings.
>    Any plans to support named mappings?  If not, I guess *someone* will
> want it (eventually).  Minor, as the patch does not introduce new
> syscalls, but having an API which is flexible for both named and anon
> mappings would be good (this is a nit, not a strong suggestion).

I apologize for not clarifying this. The initial mmap() call looks like an anonymous mapping but one could easily call 
mremap later and map any other objects in the same address space which remains shared until the mshare region is torn 
down. It is my intent to support mapping any objects in mshare region.

> 
>    The cover letter details the problem being solved and the API, but
> gives no details of the implementation.  A paragraph on the use of a
> mm_struct per-msharefs file would be helpful.

Good point. I will do that next time.

> 
>    I've only quickly scanned the patchset; not in enough detail to
> comment on each patch, but a few observations.
> 
>    o I was expecting to see mprotect() against a mshared vma to either
> be disallowed or code to support the splitting of a mshared vma.  I
> didn't see either.msharefs_delmm

Since mshare region is intended to support multiple objects being mapped in the region and different protections on 
different parts of region, mprotect should be supported and should handle splitting the mshare'd vmas. Until basic code 
is solid, it would make sense to prevent splitting vmas and add that on later. I will add this code.

> 
>    o For the case where the mshare file has been closed/unmmap but not
> unlinked, a 'mshare_data' structure will leaked when the inode is
> evicted.

You are right. mshare_evict_inode() needs to call msharefs_delmm() to clean up.

> 
>    o The alignment requirement is PGDIR_SIZE, which is very large.
> Should/could this be PMD_SIZE?

Yes, PGDIR_SIZE is large. It works for the database folks who requested this feature but PMD might be more versatile. I 
have been thinking about switching to PMD since that will make it easier to move hugetlbfs page table sharing code over 
to this code.

> 
>    o mshare should be a conditional feature (CONFIG_MSHARE ?).

I can do that. I was reluctant to add yet another CONFIG option. Since this feature is activated explicitly by userspace 
code, is it necessary to make it a config option?

> 
> 
>    I might get a chance do a finer grain review later/tomorrow.
> 
>> API
>> ===
>>
>> mshare does not introduce a new API. It instead uses existing APIs
>> to implement page table sharing. The steps to use this feature are:
>>
>> 1. Mount msharefs on /sys/fs/mshare -
>>          mount -t msharefs msharefs /sys/fs/mshare
>>
>> 2. mshare regions have alignment and size requirements. Start
>>     address for the region must be aligned to an address boundary and
>>     be a multiple of fixed size. This alignment and size requirement
>>     can be obtained by reading the file /sys/fs/mshare/mshare_info
>>     which returns a number in text format. mshare regions must be
>>     aligned to this boundary and be a multiple of this size.
>>
>> 3. For the process creating mshare region:
>>          a. Create a file on /sys/fs/mshare, for example -
>>                  fd = open("/sys/fs/mshare/shareme",
>>                                  O_RDWR|O_CREAT|O_EXCL, 0600);
>>
>>          b. mmap this file to establish starting address and size -
>>                  mmap((void *)TB(2), BUF_SIZE, PROT_READ | PROT_WRITE,
>>                          MAP_SHARED, fd, 0);
>>
>>          c. Write and read to mshared region normally.
>>
>> 4. For processes attaching to mshare'd region:
>>          a. Open the file on msharefs, for example -
>>                  fd = open("/sys/fs/mshare/shareme", O_RDWR);
>>
>>          b. Get information about mshare'd region from the file:
>>                  struct mshare_info {
>>                          unsigned long start;
>>                          unsigned long size;
>>                  } m_info;
>>
>>                  read(fd, &m_info, sizeof(m_info));
>>
>>          c. mmap the mshare'd region -
>>                  mmap(m_info.start, m_info.size,
>>                          PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
>>
>> 5. To delete the mshare region -
>>                  unlink("/sys/fs/mshare/shareme");
>>
>>
>>
>> Example Code
>> ============
>>
>> Snippet of the code that a donor process would run looks like below:
>>
>> -----------------
>>          fd = open("/sys/fs/mshare/mshare_info", O_RDONLY);
>>          read(fd, req, 128);
>>          alignsize = atoi(req);
>>          close(fd);
>>          fd = open("/sys/fs/mshare/shareme", O_RDWR|O_CREAT|O_EXCL, 0600);
>>          start = alignsize * 4;
>>          size = alignsize * 2;
>>          addr = mmap((void *)start, size, PROT_READ | PROT_WRITE,
>>                          MAP_SHARED | MAP_ANONYMOUS, 0, 0);
> 
> Typo, missing 'fd'; MAP_SHARED | MAP_ANONYMOUS, fd, 0)

Yes, you are right. I will fix that.

Thanks, Mark! I really appreciate your taking time to review this code.

--
Khalid