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 BA6D1EB64DC for ; Mon, 10 Jul 2023 09:20:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D53B6B0072; Mon, 10 Jul 2023 05:20:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 285606B0074; Mon, 10 Jul 2023 05:20:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 14D0A6B0075; Mon, 10 Jul 2023 05:20:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 056BD6B0072 for ; Mon, 10 Jul 2023 05:20:25 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id AC5D51A0304 for ; Mon, 10 Jul 2023 09:20:24 +0000 (UTC) X-FDA: 80995156368.17.F2FCFBA Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf29.hostedemail.com (Postfix) with ESMTP id 46D9E120015 for ; Mon, 10 Jul 2023 09:20:21 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=OIzkPqwV; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf29.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1688980822; a=rsa-sha256; cv=none; b=D6Cj6gg5ZAzcQrnmjimanoAo+jHrnxws7sK4n+EbD8O58zbz0XO+DJa2fvKoyJMeDS1ovB xmO8pfsxy6PJYRgh1tZwcXJ1QOq7rX6FVvqwvhTggs7mn7gdBxEQKLiWkg2E0+Gp7KddBx tMFFQ7YnXjN2mlfVkOC0YX9N8Uv4Nso= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=OIzkPqwV; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf29.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1688980822; 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=Vk0BHpyjSZ0WVmRz9vo6FsGPxkWNyVz/Eo1+VrZKwkw=; b=ByFICe8pPfoHC78OGUMGPLbxgLJvcSBHGZKkURowG/zax/Q2uCW+9Csz707xvL3xEIxkGK FOGgRUiAHQEk5gHJvZXsBcnwnJAGwk9/vxAa4OukUUY7aJy0CxAuLoig8rV20eL//7NmB+ JkJUBmcVVDs9UioFwKGO2YnZmOcSzM8= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688980821; x=1720516821; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version:content-transfer-encoding; bh=ly/MDRV2EOLHcR5c4dEoNmyijTn1dRwSPnIkbL/BJH0=; b=OIzkPqwVWI6eubkXUfZLD6xwEfN+VsEH2ZBLHInwcUgCydYTadU1lAn3 9ghWSXQKaWz1A7SR8Ej7JTkb2eNfz8ABzHAqE+uCVTAfRuFrHbEB4nLzQ MskOpHyKWzal6pO75po/Mqyn86TADx08CR4TU+9KXmT8x3BGY4I5EcRB4 oDzR+FhBDhJ6FVamHDJaOT8vkuJ/Q++yraQyEVwyeA1TXnqEMJkvQO0bM 4syKdvM878ALTxWCvGftItvcodYOzZrIva4ibQuy8MnZ+cpwNxcg0MQdE zWd4X8uC0cAnxbTu1NQnDxeADt6wlCA9mMGRhF6lXo9muP8ARdsV0guIJ g==; X-IronPort-AV: E=McAfee;i="6600,9927,10766"; a="427988497" X-IronPort-AV: E=Sophos;i="6.01,194,1684825200"; d="scan'208";a="427988497" Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2023 02:20:19 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10766"; a="670880190" X-IronPort-AV: E=Sophos;i="6.01,194,1684825200"; d="scan'208";a="670880190" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga003-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jul 2023 02:20:15 -0700 From: "Huang, Ying" To: Ryan Roberts Cc: David Hildenbrand , Matthew Wilcox , Andrew Morton , "Kirill A. Shutemov" , Yin Fengwei , Yu Zhao , Catalin Marinas , Will Deacon , Anshuman Khandual , Yang Shi , , , , Johannes Weiner , Alexander Zhu Subject: Re: [PATCH v2 4/5] mm: FLEXIBLE_THP for improved performance References: <20230703135330.1865927-1-ryan.roberts@arm.com> <20230703135330.1865927-5-ryan.roberts@arm.com> <87edlkgnfa.fsf@yhuang6-desk2.ccr.corp.intel.com> <44e60630-5e9d-c8df-ab79-cb0767de680e@arm.com> <524bacd2-4a47-2b8b-6685-c46e31a01631@redhat.com> <1e406f04-78ef-6573-e1f1-f0d0e0d5246a@redhat.com> <9dd036a8-9ba3-0cc4-b791-cb3178237728@arm.com> <87y1jofoyi.fsf@yhuang6-desk2.ccr.corp.intel.com> <6c2f3127-9334-85ba-48f6-83a9c87abde0@arm.com> Date: Mon, 10 Jul 2023 17:18:38 +0800 In-Reply-To: <6c2f3127-9334-85ba-48f6-83a9c87abde0@arm.com> (Ryan Roberts's message of "Mon, 10 Jul 2023 09:55:14 +0100") Message-ID: <874jmcf7kh.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 46D9E120015 X-Stat-Signature: 9kqqaryyb7yj4shfp7767hioqdffpmwb X-HE-Tag: 1688980821-256376 X-HE-Meta: U2FsdGVkX1/BG/Ir12iI6uXDPAUomI+iyQO5NT5LJMOafRgb/h2GxidKskz3CkWBaFaJrC/IMrdEHCMPRsqD8eerbTDfvkd3slKLTs3LWXYuK6ekacfLWMMyIIojzaN2nE6tHs9a43ju5xGJvZLyQJPLUs/lhUpc/Ap4d2v4WIKWcdEeAx9jNNywmAKxae2XRuHkEAKeCFyONFdAao05ujDvsVxNoZQSwbPIKfajydaNPUxgXu2HmOv9FZf2HF2GYsdp5i77m726QY5JzDSSCDTqrtcA8lYyoxijN48EXnl/1EibKmfF5JCHEZE0q/9XvTYjaAOPO10WQDDQwF74k5M7DlfbNt9tYF8L4j5MdxyISex9qSj41vSbByTQtvjIUj0rQN3BwQCuaWW8QLbgCnV4ZAsVXZL9JxH7MhdJtrhuoqDkCasUFRkSn55LSEwJQlQChcVaXhFjYC4KDumrvrGje3Ap7KqN+cEMV9RITOPHELggdl9piecI0zrWgizGM1jCPuLD7c4IcGqo4XBGdszbYO2Ba8UyGrzhKu4mVXsXSC80wL8mUKYHWrE3hVXhgq8HJvJktmTIhVH/RHnoEZb9/UP/T4C4Sr74vVRE0CjT7CY5gAkyTkPANsO+KTYqKyOBr2YuuY7HnoQ9SrR7HBB1FH0bd0s23o0rIhfQB1wj9JAeroGj3jkdDrvtPyUcACAxrRSjU7i5a5niJCQ2kdl/db5V/Wu69rGm+52jShrVs/AdM/xA0zQpihIu0jATSwmyLztjfQxsoUuLeNdj49dumD42lYQAKRFBtgQ2sA1QYFPo6ci12vvnB5i7PqwIrt2y724SiRELdau63T2Rg5y0jnU2wOR4cUt0yqxZWJ+TH3YaOiacPM75LYW1rTOJoUpphpOlv9JsQUjLH1IscKvT+dlLGlG4X6lK3qlQYks/nWL/qaNGpnPBhLdIjQyoo6PRcM3f2CFNyne/fXX 6VLBDZ9h Tho4JOT1tP8PStX85aALS9oXJ6D+bbYyAq2/HUpFMt00+HA/VJ53BpslicNLH9d4t+AJS0ZKA10p3Kb7u5z6HMc0KugOYiyki7t1dNTRIYn9F3uquQ+wRgX67fCejb0fy/xRkr5yKO9KDrp/yfNvuBmI8MRoZ5AA1A6BBd6cX/f3CPEm2UEWppqpe2KSNFePshkVtAGlqnaudbvt0FOUQ2maDcESYBX4b40EqK9oRl9TYh2dchZJY+BKNfJ/RJC/ZerHBwd1EbGJ3owfIF5wF7+04xRh2E4P2OH0doQUpobF1AUWwOVf+bDXbBtdvht5FaHgqSnKY8IrBDrnyCMuCh0KPJNOnTLQ7PIk4FH6P3XuROCIQ8nfY/xRr9cfkBJmakRmsAmkwX852No1AD7+4l0zIU5m6vKURvOlntgo2UjxN1D8xskQakqQD2Q== 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: Ryan Roberts writes: > On 10/07/2023 04:03, Huang, Ying wrote: >> Ryan Roberts writes: >>=20 >>> On 07/07/2023 15:07, David Hildenbrand wrote: >>>> On 07.07.23 15:57, Matthew Wilcox wrote: >>>>> On Fri, Jul 07, 2023 at 01:29:02PM +0200, David Hildenbrand wrote: >>>>>> On 07.07.23 11:52, Ryan Roberts wrote: >>>>>>> On 07/07/2023 09:01, Huang, Ying wrote: >>>>>>>> Although we can use smaller page order for FLEXIBLE_THP, it's hard= to >>>>>>>> avoid internal fragmentation completely.=C2=A0 So, I think that fi= nally we >>>>>>>> will need to provide a mechanism for the users to opt out, e.g., >>>>>>>> something like "always madvise never" via >>>>>>>> /sys/kernel/mm/transparent_hugepage/enabled.=C2=A0 I'm not sure wh= ether it's >>>>>>>> a good idea to reuse the existing interface of THP. >>>>>>> >>>>>>> I wouldn't want to tie this to the existing interface, simply becau= se that >>>>>>> implies that we would want to follow the "always" and "madvise" adv= ice too; >>>>>>> That >>>>>>> means that on a thp=3Dmadvise system (which is certainly the case f= or android and >>>>>>> other client systems) we would have to disable large anon folios fo= r VMAs that >>>>>>> haven't explicitly opted in. That breaks the intention that this sh= ould be an >>>>>>> invisible performance boost. I think it's important to set the poli= cy for >>>>>>> use of >>>>>> >>>>>> It will never ever be a completely invisible performance boost, just= like >>>>>> ordinary THP. >>>>>> >>>>>> Using the exact same existing toggle is the right thing to do. If so= meone >>>>>> specify "never" or "madvise", then do exactly that. >>>>>> >>>>>> It might make sense to have more modes or additional toggles, but >>>>>> "madvise=3Dnever" means no memory waste. >>>>> >>>>> I hate the existing mechanisms.=C2=A0 They are an abdication of our >>>>> responsibility, and an attempt to blame the user (be it the sysadmin >>>>> or the programmer) of our code for using it wrongly.=C2=A0 We should = not >>>>> replicate this mistake. >>>> >>>> I don't agree regarding the programmer responsibility. In some cases t= he >>>> programmer really doesn't want to get more memory populated than reque= sted -- >>>> and knows exactly why setting MADV_NOHUGEPAGE is the right thing to do. >>>> >>>> Regarding the madvise=3Dnever/madvise/always (sys admin decision), mem= ory waste >>>> (and nailing down bugs or working around them in customer setups) have= been very >>>> good reasons to let the admin have a word. >>>> >>>>> >>>>> Our code should be auto-tuning.=C2=A0 I posted a long, detailed outli= ne here: >>>>> https://lore.kernel.org/linux-mm/Y%2FU8bQd15aUO97vS@casper.infradead.= org/ >>>>> >>>> >>>> Well, "auto-tuning" also should be perfect for everybody, but once rea= lity >>>> strikes you know it isn't. >>>> >>>> If people don't feel like using THP, let them have a word. The "madvis= e" config >>>> option is probably more controversial. But the "always vs. never" abso= lutely >>>> makes sense to me. >>>> >>>>>> I remember I raised it already in the past, but you *absolutely* hav= e to >>>>>> respect the MADV_NOHUGEPAGE flag. There is user space out there (for >>>>>> example, userfaultfd) that doesn't want the kernel to populate any >>>>>> additional page tables. So if you have to respect that already, then= also >>>>>> respect MADV_HUGEPAGE, simple. >>>>> >>>>> Possibly having uffd enabled on a VMA should disable using large foli= os, >>>> >>>> There are cases where we enable uffd *after* already touching memory (= postcopy >>>> live migration in QEMU being the famous example). That doesn't fly. >>>> >>>>> I can get behind that.=C2=A0 But the notion that userspace knows what= it's >>>>> doing ... hahaha.=C2=A0 Just ignore the madvise flags.=C2=A0 Userspac= e doesn't >>>>> know what it's doing. >>>> >>>> If user space sets MADV_NOHUGEPAGE, it exactly knows what it is doing = ... in >>>> some cases. And these include cases I care about messing with sparse V= M memory :) >>>> >>>> I have strong opinions against populating more than required when user= space set >>>> MADV_NOHUGEPAGE. >>> >>> I can see your point about honouring MADV_NOHUGEPAGE, so think that it = is >>> reasonable to fallback to allocating an order-0 page in a VMA that has = it set. >>> The app has gone out of its way to explicitly set it, after all. >>> >>> I think the correct behaviour for the global thp controls (cmdline and = sysfs) >>> are less obvious though. I could get on board with disabling large anon= folios >>> globally when thp=3D"never". But for other situations, I would prefer t= o keep >>> large anon folios enabled (treat "madvise" as "always"), >>=20 >> If we have some mechanism to auto-tune the large folios usage, for >> example, detect the internal fragmentation and split the large folio, >> then we can use thp=3D"always" as default configuration. If my memory >> were correct, this is what Johannes and Alexander is working on. > > Could you point me to that work? I'd like to understand what the mechanis= m is. > The other half of my work aims to use arm64's pte "contiguous bit" to tel= l the > HW that a span of PTEs share the same mapping and is therefore coalesced = into a > single TLB entry. The side effect of this, however, is that we only have a > single access and dirty bit for the whole contpte extent. So I'd like to = avoid > any mechanism that relies on getting access/dirty at the base page granul= arity > for a large folio. Please take a look at the THP shrinker patchset, https://lore.kernel.org/linux-mm/cover.1667454613.git.alexlzhu@fb.com/ >>=20 >>> with the argument that >>> their order is much smaller than traditional THP and therefore the inte= rnal >>> fragmentation is significantly reduced. >>=20 >> Do you have any data for this? > > Some; its partly based on intuition that the smaller the allocation unit,= the > smaller the internal fragmentation. And partly on peak memory usage data = I've > collected for the benchmarks I'm running, comparing baseline-4k kernel wi= th > baseline-16k and baseline-64 kernels along with a 4k kernel that supports= large > anon folios (I appreciate that's not exactly what we are talking about he= re, and > it's not exactly an extensive set of results!): > > > Kernel Compliation with 8 Jobs: > | kernel | peak | > |:--------------|-------:| > | baseline-4k | 0.0% | > | anonfolio | 0.1% | > | baseline-16k | 6.3% | > | baseline-64k | 28.1% | > > > Kernel Compliation with 80 Jobs: > | kernel | peak | > |:--------------|-------:| > | baseline-4k | 0.0% | > | anonfolio | 1.7% | > | baseline-16k | 2.6% | > | baseline-64k | 12.3% | > Why is anonfolio better than baseline-64k if you always allocate 64k anonymous folio? Because page cache uses 64k in baseline-64k? We may need to test some workloads with sparse access patterns too. Best Regards, Huang, Ying >>=20 >>> I really don't want to end up with user >>> space ever having to opt-in (with MADV_HUGEPAGE) to see the benefits of= large >>> anon folios. >>> >>> I still feel that it would be better for the thp and large anon folio c= ontrols >>> to be independent though - what's the argument for tying them together? >>>