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: <8ab18141-8091-6691-ddbd-cff834a8d4d0@intel.com>
Date:   Wed, 28 Jun 2023 10:32:28 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Firefox/102.0 Thunderbird/102.11.0
Subject: Re: [PATCH v1 03/10] mm: Introduce try_vma_alloc_movable_folio()
Content-Language: en-US
To:     Ryan Roberts <ryan.roberts@arm.com>, Yu Zhao <yuzhao@google.com>
CC:     Andrew Morton <akpm@linux-foundation.org>,
        "Matthew Wilcox (Oracle)" <willy@infradead.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        David Hildenbrand <david@redhat.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Christian Borntraeger <borntraeger@linux.ibm.com>,
        Sven Schnelle <svens@linux.ibm.com>,
        "Thomas Gleixner" <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>,
        "Borislav Petkov" <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>, <linux-kernel@vger.kernel.org>,
        <linux-mm@kvack.org>, <linux-alpha@vger.kernel.org>,
        <linux-arm-kernel@lists.infradead.org>,
        <linux-ia64@vger.kernel.org>, <linux-m68k@lists.linux-m68k.org>,
        <linux-s390@vger.kernel.org>
References: <20230626171430.3167004-1-ryan.roberts@arm.com>
 <20230626171430.3167004-4-ryan.roberts@arm.com>
 <CAOUHufZKM+aS_hYQ5nDUHh74UQwWipJ27Na5Sw4n+RDqnwyWHA@mail.gmail.com>
 <CAOUHufZeFTjzO6nSFz7Y=5rBGPzY+_eeN3f8W+g0u6AqosdmuQ@mail.gmail.com>
 <ba282a84-1a0d-4ffd-0b22-ac9510a820ef@arm.com>
From:   Yin Fengwei <fengwei.yin@intel.com>
In-Reply-To: <ba282a84-1a0d-4ffd-0b22-ac9510a820ef@arm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dDEzcHhTZTFQeXZQOUFVdXpKcW1seHJnaSs4Wk4rN2xLMXZ0QWpWcm5TdERt?=
 =?utf-8?B?d1gxamxJcyt6REVCT1pzL2lnTElqRWxwV0tGWVN0UHhFcU9zUGVYcCtIUEts?=
 =?utf-8?B?UGdzV3BYdXFvUzFUV3VqVE84Nm9YbnVHdVZETWVaN3ZtMTBYL0VVZHdBOThV?=
 =?utf-8?B?VUNCTE9WcVVJRTJMcEpIdDRpSXBabU9KcVVNemJBeU81Zy9MK0RqNngyejJ0?=
 =?utf-8?B?b1MzQjl3MW1RdXNJc0lyNVZEUjNvQm85TG91QTdUdGR6NmVVNXFxTWxuajVq?=
 =?utf-8?B?R09OSVlwMERZcHdTb2dtNGRmSHh5ckFSMXhlaHI1SjFDVXNpT0YrY2xTK2Nk?=
 =?utf-8?B?b3ZJa05IbGEza1VPM1F2V0FrZ2N3aGNFa0Y4V2E4V3ZJZ2dWamsrcVpRbWtj?=
 =?utf-8?B?Y1FkNjlFY1c1K2FjWkJxMTg2dWRFbnB2SDVrSDBtVjZjQVVPZlBxTXcxaVlt?=
 =?utf-8?B?aUlObWxBL253YzFYTE5mZ283cWpSeTJqSmFqeWxZT1VjSFVaRDZVZTJPSUg2?=
 =?utf-8?B?R2wvZUlnS1JZT3VkN0ZXTlEwdUtsenlWRnUwTE44QU1ya3pCckM1RTBBc3gv?=
 =?utf-8?B?Z3AzSGhRTVlDSlcycWxPdWVkRW44UG11cEdXSVduU1dQOGZwQVIwczFiWTI2?=
 =?utf-8?B?N2VoaGRKWmZGcUVMdllVZkl0dm05SlBGcXg4aytPR2NnM01JNS9yQVVOMnlm?=
 =?utf-8?B?SmxsN3Y2S1dnaHE1UXRlQkxiWDI0MXJDdGtwUDNwNEd5N2U1ZjI1aTdyL0tt?=
 =?utf-8?B?T0c0a2RrMGVONk8yOHRZYzQxc1Z4NWRQU2tXTEdlMkRGS0hzaW9sWC9jZ0R4?=
 =?utf-8?B?c0liL0lMZVF3T1dpeWNxcUQ0SkxJZmxLSUcvUGFYL1ZXZm5aYW1SaWlZRXVw?=
 =?utf-8?B?bDVGdnBYRHc1NHBPQUVPVE40TnZmdFJmZTFqUU1XcEhNVlVUZTBTdVRJbHhK?=
 =?utf-8?B?d0c3M3VCbjBWeW5RSUExSXhyZWs0MXhyZFpQZGYrNXpXRzhVM2w4NUM4enFm?=
 =?utf-8?B?d1RNZ1FOd3dUY3JjbUxscTdwUkkwUVAvVTJMK1V0cFk2UFBhdld1b3JqNlVv?=
 =?utf-8?B?NWc4cUhEbG9KR2pWb1lQZ0k4bkRjZEJQOGVWQVJrYXZqSjA0UStCVk5wRWRs?=
 =?utf-8?B?cVBCczFGSHo4blBwdDFuYXZRY3EwV3BrTUJDcWpneVYzc3lUWTJoZ25zOG1p?=
 =?utf-8?B?UXVFcEJhWVZ6KytNcEVqUWk5R3d5dC9ZVnhZN24zL29JQXRCaHp5TCs0TjFk?=
 =?utf-8?B?R2tlbEdZaDBkRzlNeXFVdHNlSklVOWw2NjgxYnRVakRRQkREbUZUdHpvVEJ5?=
 =?utf-8?B?R09FRll0VmtzOE5Zek1iZy96b0Q2cEtkejN4WUx0TEM3YklkU0MwZTgzVDM4?=
 =?utf-8?B?SFVOVTEweFAwNFM3TVFBTDNSNng0d1BPMWxiMlFmY0tGemdHUTRKK01DL25W?=
 =?utf-8?B?Znc0TlVESXlrZGJ1OUFrQmRyNmc4R3B6Q1JJdkg2Mm9ZMGEzL1ZHMzFqYXRl?=
 =?utf-8?B?R0dTMmVRK3dxT2Z3bjR4Q3YxNThITGFQNFUyMHZOY21CcTBsNEtJZzFvdTBJ?=
 =?utf-8?B?QThHMVN4allJWDlRb2hhd3dUdVlMa0tEM05IQ21Vdzl6amx5Mkl0dkUwemZ3?=
 =?utf-8?B?NVlxYjg2MTQ1ZlZpYTNsUEkrYm9iaFRCTWFkNElrdFZDZkN1NkdQWU5aRnc0?=
 =?utf-8?B?VFBtanBQZ2VuUXJMdS9CS09FVGRlWEFFbk41ejg4d3ZZWHVjYlZ5V3NBTUd5?=
 =?utf-8?B?eTJoYXg4Sm1VRXlaSXpjVTNiYVhZRm5ubEZBS0VXVjNSalpFdU1TWkt2d3JY?=
 =?utf-8?B?cGljc3Nrd0tYWElBcFNuUmZRYTQxb01xVisrQ3F3RkEwYklFMmY1NW4yQ28x?=
 =?utf-8?B?TTluRThybk96Mzd4UlFFVUhBUERYYkRXRnhMUWxKYnl1SWQyTjZLczR4U1kr?=
 =?utf-8?B?ai9UUVBya1FCWk1PMGVYWGtpcWIrdXhFeDl3SC9vOUpCdEQ4cVE1dTg2cHF4?=
 =?utf-8?B?bFoxVEE1WGJqdkcrbTc0VnFFNnd0Q2N5cm5rZkY2ME1tQzVVdFFBZU1tWVhH?=
 =?utf-8?B?VFcwOWMvU1dpai9nbmV1ajNQbmErbUg3Mmp3eVE1RTN2VTU2VWppY0FMVisv?=
 =?utf-8?Q?HaG2RJpqa14oZ3DOVHSrtKzT7?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 506c9b40-70db-4e7b-eaeb-08db777ff4cc
X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4820.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Jun 2023 02:32:45.7608
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: xJ+qq9QzW3oXY6VVv6YSDqoiscxDAh3TtRGADrGoMtqRR0tK51HuLOP26M3oCY0glJVkxmgjBlV9sEL5oiSUjQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR11MB5259
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,
        RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,
        SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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/27/23 15:56, Ryan Roberts wrote:
> On 27/06/2023 06:29, Yu Zhao wrote:
>> On Mon, Jun 26, 2023 at 8:34 PM Yu Zhao <yuzhao@google.com> wrote:
>>>
>>> On Mon, Jun 26, 2023 at 11:14 AM Ryan Roberts <ryan.roberts@arm.com> wrote:
>>>>
>>>> Opportunistically attempt to allocate high-order folios in highmem,
>>>> optionally zeroed. Retry with lower orders all the way to order-0, until
>>>> success. Although, of note, order-1 allocations are skipped since a
>>>> large folio must be at least order-2 to work with the THP machinery. The
>>>> user must check what they got with folio_order().
>>>>
>>>> This will be used to oportunistically allocate large folios for
>>>> anonymous memory with a sensible fallback under memory pressure.
>>>>
>>>> For attempts to allocate non-0 orders, we set __GFP_NORETRY to prevent
>>>> high latency due to reclaim, instead preferring to just try for a lower
>>>> order. The same approach is used by the readahead code when allocating
>>>> large folios.
>>>>
>>>> Signed-off-by: Ryan Roberts <ryan.roberts@arm.com>
>>>> ---
>>>>  mm/memory.c | 33 +++++++++++++++++++++++++++++++++
>>>>  1 file changed, 33 insertions(+)
>>>>
>>>> diff --git a/mm/memory.c b/mm/memory.c
>>>> index 367bbbb29d91..53896d46e686 100644
>>>> --- a/mm/memory.c
>>>> +++ b/mm/memory.c
>>>> @@ -3001,6 +3001,39 @@ static vm_fault_t fault_dirty_shared_page(struct vm_fault *vmf)
>>>>         return 0;
>>>>  }
>>>>
>>>> +static inline struct folio *vma_alloc_movable_folio(struct vm_area_struct *vma,
>>>> +                               unsigned long vaddr, int order, bool zeroed)
>>>> +{
>>>> +       gfp_t gfp = order > 0 ? __GFP_NORETRY | __GFP_NOWARN : 0;
>>>> +
>>>> +       if (zeroed)
>>>> +               return vma_alloc_zeroed_movable_folio(vma, vaddr, gfp, order);
>>>> +       else
>>>> +               return vma_alloc_folio(GFP_HIGHUSER_MOVABLE | gfp, order, vma,
>>>> +                                                               vaddr, false);
>>>> +}
>>>> +
>>>> +/*
>>>> + * Opportunistically attempt to allocate high-order folios, retrying with lower
>>>> + * orders all the way to order-0, until success. order-1 allocations are skipped
>>>> + * since a folio must be at least order-2 to work with the THP machinery. The
>>>> + * user must check what they got with folio_order(). vaddr can be any virtual
>>>> + * address that will be mapped by the allocated folio.
>>>> + */
>>>> +static struct folio *try_vma_alloc_movable_folio(struct vm_area_struct *vma,
>>>> +                               unsigned long vaddr, int order, bool zeroed)
>>>> +{
>>>> +       struct folio *folio;
>>>> +
>>>> +       for (; order > 1; order--) {
>>>> +               folio = vma_alloc_movable_folio(vma, vaddr, order, zeroed);
>>>> +               if (folio)
>>>> +                       return folio;
>>>> +       }
>>>> +
>>>> +       return vma_alloc_movable_folio(vma, vaddr, 0, zeroed);
>>>> +}
>>>
>>> I'd drop this patch. Instead, in do_anonymous_page():
>>>
>>>   if (IS_ENABLED(CONFIG_ARCH_WANTS_PTE_ORDER))
>>>     folio = vma_alloc_zeroed_movable_folio(vma, addr,
>>> CONFIG_ARCH_WANTS_PTE_ORDER))
>>>
>>>   if (!folio)
>>>     folio = vma_alloc_zeroed_movable_folio(vma, addr, 0);
>>
>> I meant a runtime function arch_wants_pte_order() (Its default
>> implementation would return 0.)
> 
> There are a bunch of things which you are implying here which I'll try to make
> explicit:
> 
> I think you are implying that we shouldn't retry allocation with intermediate
> orders; but only try the order requested by the arch (arch_wants_pte_order())
> and 0. Correct? For arm64 at least, I would like the VMA's THP hint to be a
> factor in determining the preferred order (see patches 8 and 9). So I would add
> a vma parameter to arch_wants_pte_order() to allow for this.
> 
> For the case where the THP hint is present, then the arch will request 2M (if
> the page size is 16K or 64K). If that fails to allocate, there is still value in
> allocating a 64K folio (which is order 2 in the 16K case). Without the retry
> with intermediate orders logic, we would not get this.
> 
> We can't just blindly allocate a folio of arch_wants_pte_order() size because it
> might overlap with existing populated PTEs, or cross the bounds of the VMA (or a
> number of other things - see calc_anon_folio_order_alloc() in patch 10). Are you
> implying that if there is any kind of issue like this, then we should go
> directly to order 0? I can kind of see the argument from a minimizing
> fragmentation perspective, but for best possible performance I think we are
> better off "packing the bin" with intermediate orders.

One drawback of the retry is that it could introduce large tail latency (by
memory zeroing, memory reclaiming or existing populated PTEs). That may not
be appreciated by some applications. Thanks.


Regards
Yin, Fengwei

> 
> You're also implying that a runtime arch_wants_pte_order() function is better
> than the Kconfig stuff I did in patch 8. On reflection, I agree with you here. I
> think you mentioned that AMD supports coalescing 8 pages on some CPUs - so you
> would probably want runtime logic to determine if you are on an appropriate AMD
> CPU as part of the decision in that function?
> 
> The real reason for the existance of try_vma_alloc_movable_folio() is that I'm
> reusing it on the other fault paths (which are no longer part of this series).
> But I guess that's not a good reason to keep this until we get to those patches.