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 8D00FC25B75 for ; Thu, 6 Jun 2024 09:31:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E41C46B009E; Thu, 6 Jun 2024 05:31:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DF1546B00A1; Thu, 6 Jun 2024 05:31:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB8716B00A2; Thu, 6 Jun 2024 05:31:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id AF05E6B009E for ; Thu, 6 Jun 2024 05:31:32 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 6037A1C0731 for ; Thu, 6 Jun 2024 09:31:32 +0000 (UTC) X-FDA: 82199946024.15.7240012 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) by imf24.hostedemail.com (Postfix) with ESMTP id 4E993180012 for ; Thu, 6 Jun 2024 09:31:28 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=eiXEEJDn; spf=pass (imf24.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717666290; 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=8q8Fkl2jA1U5hSAvLLBPc/Mm5V5YlZfvuHx62cOLGLY=; b=nenRJuQIHaz5Pc/dDecqbuuDpCq4B7s9nfqf0cqwxvdQ2OSgd8bpep9QFW0GDcqrmM7/Ze +8GtMHbSj7LZnRT06+SFnVh+JiVg06l1e3KwuWmhsRYCgAfaTUQUSNmmoGcjMUrqUpFuPE 6cFRDL6UqaSX2MICxjTt9D/Lu4STIas= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717666290; a=rsa-sha256; cv=none; b=NYVl2uOWcD5A4uUqp7UnczRhgkYXagq7XvCsOFhKAnEaBJiaDfy+wuC0m6NOJrhqwXdXmB /EN+YfDRpprCRqcmaPBBkoEEh7Pxqkoijh8+xMFvmrjI+ozd10CPjsebJsg+6d90DZM3R7 x/aI8Y1/LnZ6PvUkTBdhXwxES1coCVw= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=eiXEEJDn; spf=pass (imf24.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1717666286; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=8q8Fkl2jA1U5hSAvLLBPc/Mm5V5YlZfvuHx62cOLGLY=; b=eiXEEJDnRadImuDaFAYchG6cd16iRfW/i4iqCeEbr0Y0IBEoKrzWGv6+Qc4dUPTi9MhN6TfGF7BcZKyiAkphIvRvVnPpjX95Utx9Er2h6d8zzb643BWNx1bIv3b0h1Oo4WyaH587tGhaJpz8cbLT/E9Wmxv97UE/DlU0J32J5Iw= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R151e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037067113;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=15;SR=0;TI=SMTPD_---0W7xuZWn_1717666283; Received: from 30.97.56.72(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0W7xuZWn_1717666283) by smtp.aliyun-inc.com; Thu, 06 Jun 2024 17:31:24 +0800 Message-ID: Date: Thu, 6 Jun 2024 17:31:23 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 0/6] add mTHP support for anonymous shmem To: David Hildenbrand , Daniel Gomez Cc: "akpm@linux-foundation.org" , "hughd@google.com" , "willy@infradead.org" , "wangkefeng.wang@huawei.com" , "ying.huang@intel.com" , "21cnbao@gmail.com" <21cnbao@gmail.com>, "ryan.roberts@arm.com" , "shy828301@gmail.com" , "ziy@nvidia.com" , "ioworker0@gmail.com" , Pankaj Raghav , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" References: <502fb3df-b42b-4f0c-a98d-348c3d544721@redhat.com> <5mezgqzg7wmd4iq2d2q3aentziosetwcll3tgdbl3mhriseyv3@pgxsux7qvxno> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 4E993180012 X-Rspam-User: X-Stat-Signature: uozf5d96nbbpczfrg81e6636p1qupcnw X-HE-Tag: 1717666288-179877 X-HE-Meta: U2FsdGVkX1++bks/4sP+9/K+8+VXlV4vAEAvLQw4RY12EWiZ8mazdPbQTXPt8oy1APHETn07kOQkbh/EaLTyOUeni7ADzUuwAqN9iwFeO8ieB/LOqp7J8brAOS1zCMMfof2195TRn9CykW/YqDQxxlZgHGTlHZnACTYOGwmPeU+hxDHQSKSD7nkbWvfQyhO/vheiUxSWCQ1JauUg+ex+II3iY9PloDqi1t3Ii4ETvi+BJEWnQoIF0EcKB+jlm4EX7uN8VtSdAIxtSok0OxQa+jfpJsSgmOSjjVUix/AupI6gwyaOjcQ8RhvikaBx2TnO4vDK7d8Oo7rQAVlE8IkftP7sEopXNBKCRJ+SeXZeOE3w7gWK/IdR0eKYn2cdoFEJKZupf6c9WRk7j24qNdkHY/7aD3BagpZ9LNX8KACPY8NMu0ipfCJ5A5Ilq8v9jyT8keEbWvEdvnIR9+qmcnh+IZ1fe7gYj7ls1kFr7cU4dG0npTeu5eQbhLMyARLmsBz2Vx4oJ7jP4r7RW+m58KPC2XiaLY29hXXoi/6mGSBZlrp878WRLAUPrr0cFAMewJ/oxiAucC7iSHDJnnFjDKzIgzKYsjttFvh0fkZ2DktfYBhzT/AwPglNliQc0t0rLpH8NMrgCS07B7V+JKoXEp/aYYvfcx3IvhzP9KnueBNynttQsjvUcJ1bllpdLOZcozXMfTW8vm/yLW6GsJ4qHuKDLdhkcSacg9r3NHTKYHnix8Mnv75dVf0inUCz8e0oaZ9FNiriZLRcdgZngzRsT5QRvCfbVMnCTFoMd+97/Ta9y5PfAfwALnR+d4WHJTndiAVchdP4oH00CDrHhj/ZpxOJEC5tUZgQlcXUqfAQlOa4pDZVBkYvemUs+dKT4jyK6TMHXOZtvMbmanE32BsmmXTEDUsUHu+B3Q6k3mxgIGUujUUHYicDOtMmFrQ57JOhm+i9G7gb4p7RKiniHJAX4Fz FPuZPRZg tolmgVgwDovzzrgdBcZimZJPJIvTwfJWZTjoXc20DiX54WdO/CxcG2vK+C8/0uLRGOaRPCyQZdh3yswaiUrbQ8mvaM47JfpxpoaOhbdGx/c+6lKJ5uvNSAjfOWTuLMhz98m/rIMwznPHKXZ90tzFVuQL8a7IjYdkE2H3NoqlpvJHRbPbzmhkm/0zrdM279TWHR6TrKh2JQYPzb/V4wRp2FP2LBwUeJMdevyFotbgp0otQRW0+zCA3AdElD4KzHgt03tHIJN3LmJRona9aS2FBdPcosCXr6B5ZX6FhahXu7n5rLentCTiehwcacwBInVGEFJfiI8uTlU9/10ykdUnlnVocWjEth/zk40m+kOe4aFxWe2IjDd1XCv9UBjRuj6LTvhFW0mQvyuYcNL0GWnTd0KSlbkPj0TI9QQ7czYXYKPYkd+9BXoWjaZgqO2s1QIynWi6JFyv72oBC97/EyI4V6yPJWoWplX3A1G9ODCp7Wjrw01iPEOZpd8Yn9EiWbbgBe/4M 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: On 2024/6/6 16:38, David Hildenbrand wrote: > On 06.06.24 05:31, Baolin Wang wrote: >> >> >> On 2024/6/4 20:05, Daniel Gomez wrote: >>> On Tue, Jun 04, 2024 at 05:45:20PM +0800, Baolin Wang wrote: >>>> >>>> >>>> On 2024/6/4 16:18, Daniel Gomez wrote: >>>>> On Fri, May 31, 2024 at 01:13:48PM +0200, David Hildenbrand wrote: >>>>>>>> >>>>>>>> As a default, we should not be using large folios / mTHP for any >>>>>>>> shmem, >>>>>>>> just like we did with THP via shmem_enabled. This is what this >>>>>>>> series >>>>>>>> currently does, and is aprt of the whole mTHP user-space >>>>>>>> interface design. >>>>>>>> >>>>>>>> Further, the mTHP controls should control all of shmem, not only >>>>>>>> "anonymous shmem". >>>>>>> >>>>>>> Yes, that's what I thought and in my TODO list. >>>>>> >>>>>> Good, it would be helpful to coordinate with Daniel and Pankaj. >>>>> >>>>> I've integrated patches 11 and 12 from the lsf RFC thread [1] on >>>>> top of Baolin's >>>>> v3 patches. You may find a version in my integration branch here >>>>> [2]. I can >>>>> attach them here if it's preferred. >>>>> >>>>> [1] >>>>> https://lore.kernel.org/all/20240515055719.32577-1-da.gomez@samsung.com/ >>>>> [2] >>>>> https://protect2.fireeye.com/v1/url?k=a23e7c06-c3b56926-a23ff749-74fe485fb347-371ca2bfd5d9869f&q=1&e=6974304e-a786-4255-93a7-57498540241c&u=https%3A%2F%2Fgitlab.com%2Fdkruces%2Flinux-next%2F-%2Fcommits%2Fnext-20240604-shmem-mthp >>>>> >>>>> The point here is to combine the large folios strategy I proposed >>>>> with mTHP >>>>> user controls. Would it make sense to limit the orders to the >>>>> mapping order >>>>> calculated based on the size and index? >>>> >>>> IMO, for !anon shmem, this change makes sense to me. We should >>>> respect the >>>> size and mTHP should act as a order filter. >>> >>> What about respecing the size when within_size flag is enabled? Then, >>> 'always' >>> would allocate mTHP enabled folios, regardless of the size. And 'never' >>> would ignore mTHP and size. So, 'never' can be used for this 'safe' >>> boot case >>> mentioned in the discussion. >> >> Looks reasonable to me. What do you think, David? >> > > That mimics existing PMD-THP behavior, right? > > With "within_size", we must not exceed the size, with "always", we may > exceed the size. Yes, I think so. >> And what about 'advise' option? Silimar to 'within_size'? > > Good question. What's the behavior of PMD-THP? I would assume it behaves > like "within_size", because in the common case we mmap (+advise) only > within the size of the file, not exceeding it. Yes, that is also my understanding. > (the always option, as I learned during the meeting, is primarily > helpful when writing to tmpfs files in an append-fashion. With > mmap()+madvise() that doesn't quite happen) >