From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 536AFC27C75 for ; Fri, 14 Jun 2024 08:00:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB7076B00A8; Fri, 14 Jun 2024 03:55:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C59AA6B00ED; Fri, 14 Jun 2024 03:55:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9D6796B00A8; Fri, 14 Jun 2024 03:55:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6204F6B0120 for ; Fri, 14 Jun 2024 03:53:59 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 16DC61C0AA2 for ; Fri, 14 Jun 2024 07:53:59 +0000 (UTC) X-FDA: 82228730598.15.5A45D38 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf17.hostedemail.com (Postfix) with ESMTP id B9A0340014 for ; Fri, 14 Jun 2024 07:53:56 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Ve2i6J5Z; spf=pass (imf17.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718351635; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6nhpYWtV3SSykoSBbf6TQf/pqeEXkjD+rzeXphjqnLI=; b=lRkKjRDVND/LuoYvnj6Z4p+m89lARPUISZZ7scH7iO5292rkW5fDWwz5IykCOCAqcIrLeh uAKrq5AtyCzVtnNIolPHaSavIOIC1MIt3RzMeZvfyzyuI4FMuxrH/eaTbRikmCi4mnYbiY FR4FUaRn/mmPzSF8fxzMSg7Pj8aTGK4= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Ve2i6J5Z; spf=pass (imf17.hostedemail.com: domain of david@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718351635; a=rsa-sha256; cv=none; b=JUnZyfpYRNAPr9DcmzTT/R4yehS8Fs757GGMoAeWqAwFP1rNrHbdDwavIX/Fw2O2LpBEo3 2NhWNBIYLSEGGJQXAniXBeXyJZX4o8BszIh+2EO9lzDkT5pr21jMd02fdVHmYotFehOb+s HjcFxmlWU0T7cVpfv75Ew1gvh/lLJjQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1718351636; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:autocrypt:autocrypt; bh=6nhpYWtV3SSykoSBbf6TQf/pqeEXkjD+rzeXphjqnLI=; b=Ve2i6J5ZwdoNHdhu4BMVemPYCRLAmKYjP7iDI1plReQG0UL2ttwkHC/YS95ijy2yE+jtZC pd59cX25tnKWHNbTgG2EAcUKOVLCeFsJFQruyAA6J9gP4ip43L9YPIUhC8LmKHbiI8rzmH j1MSoiLbtQzji9hJTEcEO2IDu+Rr5ew= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-450-MUGsTdlfOWacj0r7wK0YVg-1; Fri, 14 Jun 2024 03:53:54 -0400 X-MC-Unique: MUGsTdlfOWacj0r7wK0YVg-1 Received: by mail-wr1-f70.google.com with SMTP id ffacd0b85a97d-35e7cce4c32so1046218f8f.3 for ; Fri, 14 Jun 2024 00:53:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718351633; x=1718956433; h=content-transfer-encoding:in-reply-to:organization:autocrypt :content-language:from:references:cc:to:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=6nhpYWtV3SSykoSBbf6TQf/pqeEXkjD+rzeXphjqnLI=; b=RBi2g06GpgBjlzmslnt1kGwwgSB6HrKow9GkTI5s08bV/rdZKc5RrMCBMaFMTu78XQ W5JLpymYVO2/MiRdp6jCaKSdZJnfWqAQaoo9avIdLMnSQGBBe+SlA2WGNsv026krVY0y NNQvSc+r7albp+1ZhZumvylL+J7QawVkLUjavhBZ5QK0iOCmZ3+YxmSz/8CkevZKwGmD EcV9lrEwvGgyY987F685GOPXfaL0PhpmHUvkHiIlbGDfeWR/KtpGwddbKlSzkLb9RpHr HL93bweE1UXQ7F5sgVPA8+1ztRnYSt1gUDAf/QUz1bbFnefagDSW5HshFFT3tYXXbOjt BIBA== X-Forwarded-Encrypted: i=1; AJvYcCUnbi8SCcFnA0qAwbA+XZzFkbbFBe0u8NL6WeInMOyLQaGk6XsEhgwzx4xwuYpxODRBA+uNHkD2FS285NaAnQ6tGcg= X-Gm-Message-State: AOJu0YzjM95M8ZOHG1aEG9wTD6emnmlIbt7HLZR2Q9O4KsxEbnbKShg7 cFlvaK5bdmKNjlpc/d4cHEaoMVwRpSKnRD7Lw00TzPvlacIBtyf1AXoOOMYbe963YP29fAry0X9 /jdiJdCnMxe7aXs34ZW1EaCqP3TOnvvPXtDS2iQuU/30JK3GhEYN5BP+z X-Received: by 2002:a5d:678a:0:b0:360:7829:bb93 with SMTP id ffacd0b85a97d-3607a759cadmr1305290f8f.21.1718351633119; Fri, 14 Jun 2024 00:53:53 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFH5e+WaRHcXGdwhrwdkpaBebb4bpkozMV5izrhjt1oP+U9xgm56D438jneEHdurTkoff1Ksg== X-Received: by 2002:a5d:678a:0:b0:360:7829:bb93 with SMTP id ffacd0b85a97d-3607a759cadmr1305271f8f.21.1718351632672; Fri, 14 Jun 2024 00:53:52 -0700 (PDT) Received: from ?IPV6:2003:d8:2f4f:2b00:69b5:3684:56c:6dd5? (p200300d82f4f2b0069b53684056c6dd5.dip0.t-ipconnect.de. [2003:d8:2f4f:2b00:69b5:3684:56c:6dd5]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-360750acebcsm3592549f8f.60.2024.06.14.00.53.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Jun 2024 00:53:52 -0700 (PDT) Message-ID: Date: Fri, 14 Jun 2024 09:53:51 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 0/3] asynchronously scan and free empty user PTE pages To: Qi Zheng Cc: hughd@google.com, willy@infradead.org, mgorman@suse.de, muchun.song@linux.dev, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <02f8cbd0-8b2b-4c2d-ad96-f854d25bf3c2@redhat.com> <2cda0af6-8fde-4093-b615-7979744d6898@redhat.com> From: David Hildenbrand Autocrypt: addr=david@redhat.com; keydata= xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9 PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzSREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT7CwZgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW AgMBAh4BAheAAhkBFiEEG9nKrXNcTDpGDfzKTd4Q9wD/g1oFAl8Ox4kFCRKpKXgACgkQTd4Q 9wD/g1oHcA//a6Tj7SBNjFNM1iNhWUo1lxAja0lpSodSnB2g4FCZ4R61SBR4l/psBL73xktp rDHrx4aSpwkRP6Epu6mLvhlfjmkRG4OynJ5HG1gfv7RJJfnUdUM1z5kdS8JBrOhMJS2c/gPf wv1TGRq2XdMPnfY2o0CxRqpcLkx4vBODvJGl2mQyJF/gPepdDfcT8/PY9BJ7FL6Hrq1gnAo4 3Iv9qV0JiT2wmZciNyYQhmA1V6dyTRiQ4YAc31zOo2IM+xisPzeSHgw3ONY/XhYvfZ9r7W1l pNQdc2G+o4Di9NPFHQQhDw3YTRR1opJaTlRDzxYxzU6ZnUUBghxt9cwUWTpfCktkMZiPSDGd KgQBjnweV2jw9UOTxjb4LXqDjmSNkjDdQUOU69jGMUXgihvo4zhYcMX8F5gWdRtMR7DzW/YE BgVcyxNkMIXoY1aYj6npHYiNQesQlqjU6azjbH70/SXKM5tNRplgW8TNprMDuntdvV9wNkFs 9TyM02V5aWxFfI42+aivc4KEw69SE9KXwC7FSf5wXzuTot97N9Phj/Z3+jx443jo2NR34XgF 89cct7wJMjOF7bBefo0fPPZQuIma0Zym71cP61OP/i11ahNye6HGKfxGCOcs5wW9kRQEk8P9 M/k2wt3mt/fCQnuP/mWutNPt95w9wSsUyATLmtNrwccz63XOwU0EVcufkQEQAOfX3n0g0fZz Bgm/S2zF/kxQKCEKP8ID+Vz8sy2GpDvveBq4H2Y34XWsT1zLJdvqPI4af4ZSMxuerWjXbVWb T6d4odQIG0fKx4F8NccDqbgHeZRNajXeeJ3R7gAzvWvQNLz4piHrO/B4tf8svmRBL0ZB5P5A 2uhdwLU3NZuK22zpNn4is87BPWF8HhY0L5fafgDMOqnf4guJVJPYNPhUFzXUbPqOKOkL8ojk CXxkOFHAbjstSK5Ca3fKquY3rdX3DNo+EL7FvAiw1mUtS+5GeYE+RMnDCsVFm/C7kY8c2d0G NWkB9pJM5+mnIoFNxy7YBcldYATVeOHoY4LyaUWNnAvFYWp08dHWfZo9WCiJMuTfgtH9tc75 7QanMVdPt6fDK8UUXIBLQ2TWr/sQKE9xtFuEmoQGlE1l6bGaDnnMLcYu+Asp3kDT0w4zYGsx 5r6XQVRH4+5N6eHZiaeYtFOujp5n+pjBaQK7wUUjDilPQ5QMzIuCL4YjVoylWiBNknvQWBXS lQCWmavOT9sttGQXdPCC5ynI+1ymZC1ORZKANLnRAb0NH/UCzcsstw2TAkFnMEbo9Zu9w7Kv AxBQXWeXhJI9XQssfrf4Gusdqx8nPEpfOqCtbbwJMATbHyqLt7/oz/5deGuwxgb65pWIzufa N7eop7uh+6bezi+rugUI+w6DABEBAAHCwXwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/MpN3hD3 AP+DWgUCXw7HsgUJEqkpoQAKCRBN3hD3AP+DWrrpD/4qS3dyVRxDcDHIlmguXjC1Q5tZTwNB boaBTPHSy/Nksu0eY7x6HfQJ3xajVH32Ms6t1trDQmPx2iP5+7iDsb7OKAb5eOS8h+BEBDeq 3ecsQDv0fFJOA9ag5O3LLNk+3x3q7e0uo06XMaY7UHS341ozXUUI7wC7iKfoUTv03iO9El5f XpNMx/YrIMduZ2+nd9Di7o5+KIwlb2mAB9sTNHdMrXesX8eBL6T9b+MZJk+mZuPxKNVfEQMQ a5SxUEADIPQTPNvBewdeI80yeOCrN+Zzwy/Mrx9EPeu59Y5vSJOx/z6OUImD/GhX7Xvkt3kq Er5KTrJz3++B6SH9pum9PuoE/k+nntJkNMmQpR4MCBaV/J9gIOPGodDKnjdng+mXliF3Ptu6 3oxc2RCyGzTlxyMwuc2U5Q7KtUNTdDe8T0uE+9b8BLMVQDDfJjqY0VVqSUwImzTDLX9S4g/8 kC4HRcclk8hpyhY2jKGluZO0awwTIMgVEzmTyBphDg/Gx7dZU1Xf8HFuE+UZ5UDHDTnwgv7E th6RC9+WrhDNspZ9fJjKWRbveQgUFCpe1sa77LAw+XFrKmBHXp9ZVIe90RMe2tRL06BGiRZr jPrnvUsUUsjRoRNJjKKA/REq+sAnhkNPPZ/NNMjaZ5b8Tovi8C0tmxiCHaQYqj7G2rgnT0kt WNyWQQ== Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: ehc7meoj6sh5qde6afpzt1nsrmfi7iqj X-Rspam-User: X-Rspamd-Queue-Id: B9A0340014 X-Rspamd-Server: rspam02 X-HE-Tag: 1718351636-796911 X-HE-Meta: U2FsdGVkX18mE9DJ+EBH34kML3i7JErrDb9Ouy7qeI5f/GRIlhFRtetlNbXgc/aon7ShoDgzOTy4Mn6G4H0L8VSOJd4JWlmTRQPYum7w5SzzAE9ExNS3JJcwxBtYStbCoV2sZrv3ww0w/73EYQ52QNCS5QSTMQdovrHtdhIslop3pSxZeY4hRBdmPfp14BOhef6XhbKHn4C9kjjEEOOuet6sXu3fhJUlix0KlvVmtbcE+npjkiC2JcCL0F2FL6RT1efUXVyXBjVugnLmPZvii/gQE4iBpRB7HeVUrGDKnLoN1QS3e7R8K9O1DpDnW4tQRARbxKgqfB4wRcqcsqtzYvoPH32CsQfurRnA4rl1+UEXRKahXq/hvhp2CvfpDjCUgpuTiVbpg/uPbwanLMqVQjoKrG0PEwlRsY05cUufGQruZ1NXlACd5WOiM4hSBpIle0jtnqy1wYsBonW9j/96L1FURfGkJzPjIY+Gh1P7D1/WrRS41oV5V6CgiD8fvW/mXj8HRkUZigf5JyhHwsrwFRLIrB3tZPgGlISr+f3qv0Npu3z57zfyYZH+ZDr+YYselSmzJdGLlGLZjtO9CBw49UBySyN6bS5h6HBfufizZ8HlG/aPWnIvR/RXclIOa/0wRS/A2JqfIgazR7f/L/lmd8m10OefDbap9kKsVoC5M2QRO10WmxMp8ih1zAPPdu4rknj2CfrNgigXHmMnfRMMpTi4tmXWodxYQk7okrHE+t23xws/Q+lQ4t35VxR7chbOFogAYwvsVe+jCfnormsWxaQOeAjcEGqajPf5vVBAHGmPR7rOGeHz0KBHWejSD4Q4cN5GrsyiG4ohnsXWcE3Y6fXPSK/IONR/xmGY07hKSpKQMVOkvkw+MVf4BgHKmFksO3fYZrCdwcsG8KEUgmA9w+vXrMWdPPm9RaA4fLWSRNBBj5zewPWuYFw7KXHSM9/x7T4yCcFvrn2iak5sSrg 8G7DjMQz JuBNUg5hV9wRoExQ1jj9BnOjWbGVWRGDdkI1UzeeUdDPlXvyyliNxdwTCK3qlDBub3fFs2vB1iiqoUd2hw364C1Py+Tj38eXQPxJVnvaHbPfm7ojlHeuV2dp26TsdcQgoHsDYAYtDIqQYZ0KpyMGYM7VJh4R4msltPCLlx11egfykengUSeroJ/ojqhsLxnxegiwHr0bzoBuNYzWNx58zzkEGLn1ZivnUWfqNDD005QgQnewNni3WAIf45oiRxfH37BXG1F/aS8afUjr3EwkGIJxtKhH5UVhQg7jgqixRhzZAjPW3vysThOp9TQmQKyRCxYxOnLHZBp/flagKUU4GJwsVCjxNKEg6Ih65yBRf/aGgcYnJJaVj0HxVzTQ/xEI+EB4IU0zDc+yokvwFq4SGQWpOWnau1XUs7TfAigTejrsJN8VbcfjrFFAkqbAvurOzcFVb/ZjhcA9lxCykpZItjEOCyhlHn7qTYrXcYgg7B0j6sgFTCAUHR7MuzgEnNBijOvSs X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: >> My thinking is, we start with a madvise(MADV_PT_RECLAIM) that will >> synchronously try to reclaim page tables without any asynchronous work. >> >> Similar to MADV_COLLAPSE that only does synchronous work. Of course, > > This is feasible, but I worry that some user-mode programs may not be > able to determine when to call it. Some yes, but others clearly :) Meaning, it's one step into the right direction without having to worry about asynchronous work in the kernel for now. That doesn't mean that asynchronous option is off the table. > > My previous idea was to do something similar to madvise(MADV_HUGEPAGE), > just mark the vma as being able to reclaim the pgtable, and then hand > it over to the background thread for asynchronous reclaim. That's one option, although there might be workloads where you really don't have to scan asynchronously and possibly repeatedly. For example, after virtio-mem discarded some memory it hotunplugged from a VM using MADV_DONTNEED (in a sequence of multiple steps), it could just setup a timer to free up page tables after a while exactly once. No need to scan repeatedly / multiple times if virtio-mem didn't remove any memory from a VM. For memory allocators it could be similar: trigger it once (from another thread?) on a range after sufficient freeing happened. If the workload is mostly idle, there might not be a need to free up memory. (mostly focused on anonymous memory + shmem for now. With file-backed memory it might be different, but that has so far not been the biggest consumer we saw regarding page tables.) Of course, for real asynchronous/automatic scanning in the kernel, one could try finding clues when scanning is reasonable: for example, mark page tables that have been scanned and there was nothing to reclaim, and mark page tables when modifying them. But such optimizations are rather future work I guess, because devil is in the detail. > >> if we don't need any heavy locking for reclaim, we might also just >> try reclaiming during MADV_DONTNEED when spanning a complete page > > I think the lock held by the current solution is not too heavy and > should be acceptable. > > But for MADV_FREE case, it still needs to be handled by > madvise(MADV_PT_RECLAIM) or asynchronous work. Yes. Interestingly, reclaim code might be able to do that scanning + reclaim if locking is cheap. > >> table. That won't sort out all cases where reclaim is possible, but >> with both approaches we could cover quite a lot that were discovered >> to really result in a lot of emprt page tables. > > Yes, agree. > >> >> On top, we might implement some asynchronous scanning later, This is, >> of course, TBD. Maybe we could wire up other page table scanners >> (khugepaged ?) to simply reclaim empty page tables it finds as well? > > This is also an idea. Another option may be some pgtable scanning paths, > such as MGLRU. > Exactly. >> >>> >>>> >>>>> >>>>> When scanning, we can filter out some unsuitable vmas: >>>>> >>>>>       - VM_HUGETLB vma >>>>>       - VM_UFFD_WP vma >>>> >>>> Why is UFFD_WP unsuitable? It should be suitable as long as you make >>>> sure to really only remove page tables that are all pte_none(). >>> >>> Got it, I mistakenly thought pte_none() covered pte marker case until >>> I saw pte_none_mostly(). >> >> I *think* there is one nasty detail, and we might need an arch callback >> to test if a pte is *really* can be reclaimed: for example, s390x might >> require us keeping some !pte_none() page tables. >> >> While a PTE might be none, the s390x PGSTE (think of it as another >> 8byte per PTE entry stored right next to the actual page table >> entries) might hold data we might have to preserve for our KVM guest. > > Oh, thanks for adding this background information! > >> >> But that should be easy to wire up. > > That's good! > >> >>> >>>> >>>>>       - etc >>>>> And for some PTE pages that spans multiple vmas, we can also skip. >>>>> >>>>> For locking: >>>>> >>>>>       - use the mmap read lock to traverse the vma tree and pgtable >>>>>       - use pmd lock for clearing pmd entry >>>>>       - use pte lock for checking empty PTE page, and release it after >>>>> clearing >>>>>         pmd entry, then we can capture the changed pmd in >>>>> pte_offset_map_lock() >>>>>         etc after holding this pte lock. Thanks to this, we don't need >>>>> to hold the >>>>>         rmap-related locks. >>>>>       - users of pte_offset_map_lock() etc all expect the PTE page to >>>>> be stable by >>>>>         using rcu lock, so use pte_free_defer() to free PTE pages. >>>> >>>> I once had a protoype that would scan similar to GUP-fast, using the >>>> mmap lock in read mode and disabling local IRQs and then walking the >>>> page table locklessly (no PTLs). Only when identifying an empty page and >>>> ripping out the page table, it would have to do more heavy locking (back >>>> when we required the mmap lock in write mode and other things). >>> >>> Maybe mmap write lock is not necessary, we can protect it using pmd lock >>> && pte lock as above. >> >> Yes, I'm hoping we can do that, that will solve a lot of possible issues. > > Yes, I think the protection provided by the locks above is enough. Of > course, it would be better if more people could double-check it. > >> >>> >>>> >>>> I can try digging up that patch if you're interested. >>> >>> Yes, that would be better, maybe it can provide more inspiration! >> >> I pushed it to >>     https://github.com/davidhildenbrand/linux/tree/page_table_reclaim >> >> I suspect it's a non-working version (and I assume the locking is >> broken, there >> are no VMA checks, etc), it's an old prototype. Just to give you an idea >> about the >> lockless scanning and how I started by triggering reclaim only when >> kicked-off by >> user space. > > Many thanks! But I'm worried that on some platforms disbaling the IRQ > might be more expensive than holding the lock, such as arm64? Not sure. Scanning completely lockless (no mmap lock, not PT locks), means that -- as long as there is not much to reclaim (for most workloads the common case!) -- you would not affect the workload at all. Take a look at the khugepaged logic that does mmap_read_trylock(mm) and makes sure to drop the mmap lock frequently due to khugepaged_pages_to_scan, to not affect the workload too much while scanning. > >> >>> >>>> >>>> We'll have to double check whether all anon memory cases can *properly* >>>> handle pte_offset_map_lock() failing (not just handling it, but doing >>>> the right thing; most of that anon-only code didn't ever run into that >>>> issue so far, so these code paths were likely never triggered). >>> >>> Yeah, I'll keep checking this out too. >>> >>>> >>>> >>>>> For the path that will also free PTE pages in THP, we need to recheck >>>>> whether the >>>>> content of pmd entry is valid after holding pmd lock or pte lock. >>>>> >>>>> 4. TODO >>>>> ======= >>>>> >>>>> Some applications may be concerned about the overhead of scanning and >>>>> rebuilding >>>>> page tables, so the following features are considered for >>>>> implementation in the >>>>> future: >>>>> >>>>>       - add per-process switch (via prctl) >>>>>       - add a madvise option (like THP) >>>>>       - add MM_PGTABLE_SCAN_DELAY/MM_PGTABLE_SCAN_SIZE control (via >>>>> procfs file) >>>>> Perhaps we can add the refcount to PTE pages in the future as well, >>>>> which would >>>>> help improve the scanning speed. >>>> >>>> I didn't like the added complexity last time, and the problem of >>>> handling situations where we squeeze multiple page tables into a single >>>> "struct page". >>> >>> OK, except for refcount, do you think the other three todos above are >>> still worth doing? >> >> I think the question is from where we start: for example, only synchronous >> reclaim vs. asynchonous reclaim. Synchronous reclaim won't really affect >> workloads that do not actively trigger it, so it raises a lot less >> eyebrows. ... >> and some user space might have a good idea where it makes sense to try to >> reclaim, and when. >> >> So the other things you note here rather affect asynchronous reclaim, and >> might be reasonable in that context. But not sure if we should start >> with doing >> things asynchronously. > > I think synchronous and asynchronous have their own advantages and > disadvantages, and are complementary. Perhaps they can be implemented at > the same time? No strong opinion, something synchronous sounds to me like the low-hanging fruit, that could add the infrastructure to be used by something more advanced/synchronously :) -- Cheers, David / dhildenb