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 X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B86F6C43461 for ; Thu, 10 Sep 2020 15:15:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 424A820C09 for ; Thu, 10 Sep 2020 15:15:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="AbrgEW9T" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 424A820C09 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9D80C6B0062; Thu, 10 Sep 2020 11:15:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 989B56B0070; Thu, 10 Sep 2020 11:15:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8524D8E0005; Thu, 10 Sep 2020 11:15:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id 6CB806B0062 for ; Thu, 10 Sep 2020 11:15:23 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 32129181AEF23 for ; Thu, 10 Sep 2020 15:15:23 +0000 (UTC) X-FDA: 77247500526.04.drink42_150ceed270e7 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id D0ED3800E112 for ; Thu, 10 Sep 2020 15:15:22 +0000 (UTC) X-HE-Tag: drink42_150ceed270e7 X-Filterd-Recvd-Size: 9823 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf27.hostedemail.com (Postfix) with ESMTP for ; Thu, 10 Sep 2020 15:15:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1599750921; 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=x0Dzw4EXUB8Gad1df8MZePd7Ws6OGtwvrfdwG/tOL4M=; b=AbrgEW9TAzxsbtG9xiDAYCzswH9TBRR7O2iaXbZcbvhI9yhuCaI8EnlR64Ynv2VPk9a77Y m53FK/FaWfq0Zfa2O9ojeH4lThO8cygN8IJek6nXybiWDPjXPULg0J5wAF4g9RyglNKMkV NFnBLEwwxCjfq8fp1jSK/Y9ACjTHxVQ= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-553-BDo1H3fnNiaOKK0H12zsgg-1; Thu, 10 Sep 2020 11:15:17 -0400 X-MC-Unique: BDo1H3fnNiaOKK0H12zsgg-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 64DFD8015A5; Thu, 10 Sep 2020 15:15:14 +0000 (UTC) Received: from [10.36.113.88] (ovpn-113-88.ams2.redhat.com [10.36.113.88]) by smtp.corp.redhat.com (Postfix) with ESMTP id 75AC119C66; Thu, 10 Sep 2020 15:15:10 +0000 (UTC) Subject: Re: [RFC PATCH 00/16] 1GB THP support on x86_64 To: Zi Yan Cc: Michal Hocko , Rik van Riel , Roman Gushchin , "Kirill A. Shutemov" , linux-mm@kvack.org, "Kirill A . Shutemov" , Matthew Wilcox , Shakeel Butt , Yang Shi , David Nellans , linux-kernel@vger.kernel.org, Vlastimil Babka , Mel Gorman References: <20200902180628.4052244-1-zi.yan@sent.com> <20200903142300.bjq2um5y5nwocvar@box> <20200903163020.GG60440@carbon.dhcp.thefacebook.com> <8e677ead-206d-08dd-d73e-569bd3803e3b@redhat.com> <7E20392E-5ED7-4C22-9555-F3BAABF3CBE9@nvidia.com> <20200908143503.GE26850@dhcp22.suse.cz> <7ed82cb06074b30c2956638082c515fb179f69a3.camel@surriel.com> <20200909070445.GA7348@dhcp22.suse.cz> <054d02f3b34d9946905929ff268b685c91494b3e.camel@surriel.com> <6135d2c5-2a74-6ca8-4b3b-8ceb25c0d4b1@redhat.com> <20200910073213.GC28354@dhcp22.suse.cz> <9ffa345f-fd45-aeac-691d-54d1364bff6d@redhat.com> <46604da8-55d0-111d-7854-cbaa8bb65925@redhat.com> <3684BEAF-C8A2-4EEC-8FC2-55EA5F8F7DA5@nvidia.com> From: David Hildenbrand Autocrypt: addr=david@redhat.com; prefer-encrypt=mutual; keydata= mQINBFXLn5EBEAC+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 B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABtCREYXZpZCBIaWxk ZW5icmFuZCA8ZGF2aWRAcmVkaGF0LmNvbT6JAlgEEwEIAEICGwMGCwkIBwMCBhUIAgkKCwQW 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/mWutNPt95w9wSsUyATLmtNrwccz63W5Ag0EVcufkQEQAOfX3n0g0fZz 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+w6DABEBAAGJAjwEGAEIACYCGwwWIQQb2cqtc1xMOkYN/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 GmbH Message-ID: <4b3006cf-3391-6839-904e-b415613198cb@redhat.com> Date: Thu, 10 Sep 2020 17:15:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: <3684BEAF-C8A2-4EEC-8FC2-55EA5F8F7DA5@nvidia.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Rspamd-Queue-Id: D0ED3800E112 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 Content-Transfer-Encoding: quoted-printable 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: On 10.09.20 16:41, Zi Yan wrote: > On 10 Sep 2020, at 10:34, David Hildenbrand wrote: >=20 >>>> As long as we stay in safe zone boundaries you get a benefit in most >>>> scenarios. As soon as we would have a (temporary) workload that woul= d >>>> require more unmovable allocations we would fallback to polluting so= me >>>> pageblocks only. >>> >>> The idea would work well until unmoveable pages begin to overflow int= o >>> ZONE_PREFER_MOVABLE or we move the boundary of ZONE_PREFER_MOVABLE to >>> avoid unmoveable page overflow. The issue comes from the lifetime of >>> the unmoveable pages. Since some long-live ones can be around the bou= ndary, >>> there is no guarantee that ZONE_PREFER_MOVABLE cannot grow back >>> even if other unmoveable pages are deallocated. Ultimately, >>> ZONE_PREFER_MOVABLE would be shrink to a small size and the situation= is >>> back to what we have now. >> >> As discussed this would not happen in the usual case in case we size i= t >> reasonable. Of course, if you push it to the extreme (which was never >> suggested!), you would create mess. There is always a way to create a >> mess if you abuse such mechanism. Also see Rik's reply regarding recla= im. >> >>> >>> OK. I have a stupid question here. Why not just grow pageblock to a l= arger >>> size, like 1GB? So the fragmentation of unmoveable pages will be at l= arger >>> granularity. But it is less likely unmoveable pages will be allocated= at >>> a movable pageblock, since the kernel has 1GB pageblock for them afte= r >>> a pageblock stealing. If other kinds of pageblocks run out, moveable = and >>> reclaimable pages can fall back to unmoveable pageblocks. >>> What am I missing here? >> >> Oh no. For example pageblocks have to completely fit into a single >> section (that's where metadata is maintained). Please refrain from >> suggesting to increase the section size ;) >=20 > Thank you for the explanation. I have no idea about the restrictions on > pageblock and section. Out of curiosity, what prevents the growth of > the section size? The section size (and based on that the Linux memory block size) defines - the minimum size in which we can add_memory() - the alignment requirement in which we can add_memory() This is applicable - in physical environments, where the bios will decide where to place DIMMs/NVDIMMs. The coarser the granularity, the less memory we might be able to make use of in corner cases. - in virtualized environments, where we want to add memory in fairly small granularity. The coarser the granularity, the less flexibility we have. arm64 has a section size of 1GB (and a THP/MAX_ORDER - 1 size of 512MB with 64k base pages :/ ). That already turned out to be a problem - see [1] regarding thoughts on how to shrink the section size. I once read about thoughts of switching to 2MB THP on arm64 with any base page size, not sure if that will become real at one point (and we might be able to reduce the pageblock size there as well ... ) [1] https://lkml.kernel.org/r/AM6PR08MB40690714A2E77A7128B2B2ADF7700@AM6PR08M= B4069.eurprd08.prod.outlook.com See [1] as >=20 > =E2=80=94 > Best Regards, > Yan Zi >=20 --=20 Thanks, David / dhildenb