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 478B4C2BD09 for ; Mon, 1 Jul 2024 18:20:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5790E6B0092; Mon, 1 Jul 2024 14:20:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 532556B0093; Mon, 1 Jul 2024 14:20:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3A2D16B0095; Mon, 1 Jul 2024 14:20:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 17D0F6B0092 for ; Mon, 1 Jul 2024 14:20:43 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8B13081D59 for ; Mon, 1 Jul 2024 18:20:42 +0000 (UTC) X-FDA: 82291999524.14.EB440C6 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf13.hostedemail.com (Postfix) with ESMTP id A893B2000B for ; Mon, 1 Jul 2024 18:20:40 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RJp7p79k; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719858024; a=rsa-sha256; cv=none; b=qqGebsobeu50DJenUa/Mt57qoWBkYnAdWa33k91dqYUoOf9h3Ni/NqrXeR/+JSZrtKs3Xt W0eYJ4+CxeAfvI9moXQutX4aveJQzq7l0fSlYgGr8TQWaa7eNwfsP1+LZWfy4VO+4/pGCP l2KIxtmatxz+cfsIQdfjkEUjgVoLdIE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RJp7p79k; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf13.hostedemail.com: domain of shy828301@gmail.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=shy828301@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719858024; 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=xWE6SkHai2dr4PJhwkPcdxBi9e64Tm0a2kZhQnrC0lU=; b=nfIx4T5b1gMC4nxyJgSSqOqwL1m4SRlwNsZoRT09td7jVzTHapazjtpVFQUvUsuFyb8V1A KC1lJsaUc7YIYbRI0tGEhn46vRDc3YM50kYqRlCbhmYMG19KLUpYN31/b30JB2nKiutNOv eLWR9jwtwET4RGsNLSKSUuiQ/6wLBMY= Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-57d1d614049so840877a12.1 for ; Mon, 01 Jul 2024 11:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719858039; x=1720462839; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=xWE6SkHai2dr4PJhwkPcdxBi9e64Tm0a2kZhQnrC0lU=; b=RJp7p79kGlwtKbVYi8vZO4I+CC57lSxvlTTGQvOB9GvT0ZJcVEeWQOqnQnyTlMpfVr dU8/mBqFiYuROA+53sJPJr69twfk+w2SocyLS+xGbce1xS5olWNuFCkPRF/I33nB4Dbg 1D4wEFpRgRBsQDMLJ8vJmmEu7cmDApmsAwRlt9RA7ShQjSkPLuksdKvxdgQSCmoA8HPN tEDrQoBXBm7rNOM8cLRU8gNltgSsiSVQ95HZlZNA9bAX0fIamp5hfvQ6B184/zHWQ30T NEkK/vsoecA3pk8PlkqNxcFd0RP9+UDAo1iwDyAgS8JJbsJc2O+UysmthdXK3/ccLInK BLsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719858039; x=1720462839; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=xWE6SkHai2dr4PJhwkPcdxBi9e64Tm0a2kZhQnrC0lU=; b=L8dtpOy6o9mbTPTCWg4CJiTrWerEyWocJkAcVep91nRd/SeGFnqGNBAUq8sjU8UvXT SVsu8rtz8EHsjpNtc0Df8o3fQsRoOUXET9Bbfaz2eblDUTw5FztOmvi975i0dYNDm3Oy Rj4zKrYIEZkEClgVjjs+nv3yFhNzTLHeBoC6tBpGFJsigGph5/XqmnqzDo6Ky0VznYtI okN2X6m9CfW6LdvmpZdujtebSVpdltUKniewqMI54eebMQeF8VuxzGCFujtn/lGdmnjS SRCTsONX67oGlLsDAanwnY7mpJeXfrA+tlKRo5wzJTT8xospsvFfMIbmjauMeHhPEhUA af6g== X-Forwarded-Encrypted: i=1; AJvYcCWI1phmgu5zwESl166ILJ0sz74LqLhnZAXOMCFeEdfWgfLTdzaedZFC6Z0M7LDnjvs1xYfV06AlTLErHn2rTLgrkR8= X-Gm-Message-State: AOJu0Yx2geohvZheM7qE6kVCdzlFaUH0wGOEHKjIFH30jRfEFYzlHxuN sFDWeV8umYyOCXIA1o0QdapZkIzDw8VuuFbxWD8rAVsV/hzmSMZW6KmaRM1baRCp1S2CgYNeH9Z 0ZqeXPGsBuUm5upl9b09qqEJQqNs= X-Google-Smtp-Source: AGHT+IETj650C+A8QNY2L/tY1xZJGI/lrVKRxHZXvH83tdlSO0bvAHBQp9F1MmdOCq9YhRYFUgrqTDgjD0mP1hk32zY= X-Received: by 2002:a05:6402:2712:b0:57c:a422:677b with SMTP id 4fb4d7f45d1cf-5879ede2763mr4921647a12.8.1719858038669; Mon, 01 Jul 2024 11:20:38 -0700 (PDT) MIME-Version: 1.0 References: <20240628104926.34209-1-libang.li@antgroup.com> <4b38db15-0716-4ffb-a38b-bd6250eb93da@arm.com> <4d54880e-03f4-460a-94b9-e21b8ad13119@linux.alibaba.com> <516aa6b3-617c-4642-b12b-0c5f5b33d1c9@arm.com> <597ac51e-3f27-4606-8647-395bb4e60df4@redhat.com> <6f68fb9d-3039-4e38-bc08-44948a1dae4d@arm.com> <992cdbf9-80df-4a91-aea6-f16789c5afd7@redhat.com> <2e0a1554-d24f-4d0d-860b-0c2cf05eb8da@arm.com> <06c74db8-4d10-4a41-9a05-776f8dca7189@redhat.com> <429f2873-8532-4cc8-b0e1-1c3de9f224d9@arm.com> <7a0bbe69-1e3d-4263-b206-da007791a5c4@redhat.com> In-Reply-To: <7a0bbe69-1e3d-4263-b206-da007791a5c4@redhat.com> From: Yang Shi Date: Mon, 1 Jul 2024 11:20:27 -0700 Message-ID: Subject: Re: [PATCH] support "THPeligible" semantics for mTHP with anonymous shmem To: David Hildenbrand Cc: Ryan Roberts , Baolin Wang , Bang Li , hughd@google.com, akpm@linux-foundation.org, wangkefeng.wang@huawei.com, ziy@nvidia.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A893B2000B X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: n8yydeig94g8sqriuskq8t6qegu3ju9e X-HE-Tag: 1719858040-309083 X-HE-Meta: U2FsdGVkX1/DOfyeg4skh/YekkzniXIXVtYuW44uCOEAsxOJY7U2AohESTgN8cWlsZyOe632LBBVt6V3torIsT5LShM4M5f+w/TZBCodxxcs5KBTIMTjAgz5lyEHg8Net2wr0JsvvDZI7SISJZgN/DBayKTMds7wNwNmuh4MqKuUPMoHcSOwyAdBpjqTte72sm29q+5hlK35eUfOXed7yeD1VKY7EuqIvZsbyQ5s2EnbVbwmnI1pMTAAqH++lJgmPaWBDxOepUc0bwXn3vRd69/i+vJ62yVXt2KmRmJVnR366H4A3W4aRwlzJ15VnnErrwGGiljZh1bau9uz4dxR1OG41RG7IuCb+ftCw9llzjAnWVe9wxfn7ojCHycFgZpXcYKV5aRHLVm5m2EQ6nRKyrnQYeWvALpKluDVEC/i6lnWvZE6vwxk2XpLPNJkrBagzgmV6S44xnrr2WFe43ntam8JiYmTkbKyeyvn9tdzxBOzm3gDk+LC4VSTX2/tndg3Pt+JLHJj7/8njVgypRQse1SDiKSFrTfp4lL4oW9Bh9tfmxcqNHnFRf6KZLxRIhQ4dg75ErxyXHGuQ9/j+u2LcV38U7k3tyfpbh5NrsIou8EVxP78ZeeesAX2ik64eKrDIn82Jb9CFDpI1QCGLerHA6FbYKGPFaivxbgT6Qa7zyWHzVrAraPBwGci2Cxc32LidPkh0C93+Oo2lMEfV5e+r3PzpZ+xWKVIKT4yWLdT0hkpVhcc0y2FvPbxVjZm2xTLmslb2I/zFnI0hRsGdUrWsdClDliMQDJEM3QzD412fkqZb4n+KRd/RZY385XOXhCYWCJXJf85jTl1/ahzRRF8rjstrxb/Mnm9ucGb7tKOC0NUW/DJ53dtHtqo/8mkFQvyrv04vAbJfcVThnyUnr0YwQT7p1uzByiNZEeKgQLKR7EVWSXlSvj9pratT9iH0/oyeutpmabM/OBeKYFN6v+ zrKj2pQy hS0YPeHFZev73e8L0HiKTWrszCQ73ttMek0BwqZxKQ9QjCVtdGTFW5TYPkxdNxvNuikhiADYu1QwB51/gIqo4pfIPs7p/3pt9CCBnyNwdEItz1VLvWn/X4hykY4kdYBzvgJQ6OCZ4UO5acNkR5fExjx2NXViw6ItFEgxVJBJlc+RKiUzL7Z+3eBVyb6K0te4nDT6d7/3iAwtjQH5u1TtTXex2Vkvr5YdJmO8bqCjOr7noRcG6wI2Gc0uIF/wuKm0sBsvTGClDC+Z+LaF8bztJ/xexrjxpP/9TFKNyjh7ojroFnp2CQdJQfuL/aZ9Dz5K38yJHnrnB39yCTK4Vz1ULh88PHInDV/ahWAFVTIkkoDt1vt0h6Rvp208DtxYtFo7wncTN 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 Mon, Jul 1, 2024 at 3:23=E2=80=AFAM David Hildenbrand = wrote: > > On 01.07.24 12:16, Ryan Roberts wrote: > > On 01/07/2024 10:17, David Hildenbrand wrote: > >> On 01.07.24 11:14, Ryan Roberts wrote: > >>> On 01/07/2024 09:57, David Hildenbrand wrote: > >>>> On 01.07.24 10:50, Ryan Roberts wrote: > >>>>> On 01/07/2024 09:48, David Hildenbrand wrote: > >>>>>> On 01.07.24 10:40, Ryan Roberts wrote: > >>>>>>> On 01/07/2024 09:33, Baolin Wang wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2024/7/1 15:55, Ryan Roberts wrote: > >>>>>>>>> On 28/06/2024 11:49, Bang Li wrote: > >>>>>>>>>> After the commit 7fb1b252afb5 ("mm: shmem: add mTHP support fo= r > >>>>>>>>>> anonymous shmem"), we can configure different policies through > >>>>>>>>>> the multi-size THP sysfs interface for anonymous shmem. But > >>>>>>>>>> currently "THPeligible" indicates only whether the mapping is > >>>>>>>>>> eligible for allocating THP-pages as well as the THP is PMD > >>>>>>>>>> mappable or not for anonymous shmem, we need to support semant= ics > >>>>>>>>>> for mTHP with anonymous shmem similar to those for mTHP with > >>>>>>>>>> anonymous memory. > >>>>>>>>>> > >>>>>>>>>> Signed-off-by: Bang Li > >>>>>>>>>> --- > >>>>>>>>>> fs/proc/task_mmu.c | 10 +++++++--- > >>>>>>>>>> include/linux/huge_mm.h | 11 +++++++++++ > >>>>>>>>>> mm/shmem.c | 9 +-------- > >>>>>>>>>> 3 files changed, 19 insertions(+), 11 deletions(-) > >>>>>>>>>> > >>>>>>>>>> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > >>>>>>>>>> index 93fb2c61b154..09b5db356886 100644 > >>>>>>>>>> --- a/fs/proc/task_mmu.c > >>>>>>>>>> +++ b/fs/proc/task_mmu.c > >>>>>>>>>> @@ -870,6 +870,7 @@ static int show_smap(struct seq_file *m, v= oid *v) > >>>>>>>>>> { > >>>>>>>>>> struct vm_area_struct *vma =3D v; > >>>>>>>>>> struct mem_size_stats mss =3D {}; > >>>>>>>>>> + bool thp_eligible; > >>>>>>>>>> smap_gather_stats(vma, &mss, 0); > >>>>>>>>>> @@ -882,9 +883,12 @@ static int show_smap(struct seq_fil= e *m, void > >>>>>>>>>> *v) > >>>>>>>>>> __show_smap(m, &mss, false); > >>>>>>>>>> - seq_printf(m, "THPeligible: %8u\n", > >>>>>>>>>> - !!thp_vma_allowable_orders(vma, vma->vm_flags, > >>>>>>>>>> - TVA_SMAPS | TVA_ENFORCE_SYSFS, THP_ORDERS_ALL)= ); > >>>>>>>>>> + thp_eligible =3D !!thp_vma_allowable_orders(vma, vma->vm_= flags, > >>>>>>>>>> + TVA_SMAPS | TVA_ENFORCE_SYSFS, THP_OR= DERS_ALL); > >>>>>>>>>> + if (vma_is_anon_shmem(vma)) > >>>>>>>>>> + thp_eligible =3D > >>>>>>>>>> !!shmem_allowable_huge_orders(file_inode(vma->vm_file), > >>>>>>>>>> + vma, vma->vm_pgoff, thp_eligible)= ; > >>>>>>>>> > >>>>>>>>> Afraid I haven't been following the shmem mTHP support work as = much as I > >>>>>>>>> would > >>>>>>>>> have liked, but is there a reason why we need a separate functi= on for > >>>>>>>>> shmem? > >>>>>>>> > >>>>>>>> Since shmem_allowable_huge_orders() only uses shmem specific log= ic to > >>>>>>>> determine > >>>>>>>> if huge orders are allowable, there is no need to complicate the > >>>>>>>> thp_vma_allowable_orders() function by adding more shmem related= logic, > >>>>>>>> making > >>>>>>>> it more bloated. In my view, providing a dedicated helper > >>>>>>>> shmem_allowable_huge_orders(), specifically for shmem, simplifie= s the logic. > >>>>>>> > >>>>>>> My point was really that a single interface (thp_vma_allowable_or= ders) > >>>>>>> should be > >>>>>>> used to get this information. I have no strong opinon on how the > >>>>>>> implementation > >>>>>>> of that interface looks. What you suggest below seems perfectly r= easonable > >>>>>>> to me. > >>>>>> > >>>>>> Right. thp_vma_allowable_orders() might require some care as discu= ssed in > >>>>>> other > >>>>>> context (cleanly separate dax and shmem handling/orders). But that= would be > >>>>>> follow-up cleanups. > >>>>> > >>>>> Are you planning to do that, or do you want me to send a patch? > >>>> > >>>> I'm planning on looking into some details, especially the interactio= n with large > >>>> folios in the pagecache. I'll let you know once I have a better idea= what > >>>> actually should be done :) > >>> > >>> OK great - I'll scrub it from my todo list... really getting things d= one today :) > >> > >> Resolved the khugepaged thiny already? :P > >> > >> [khugepaged not active when only enabling the sub-size via the 2M fold= er IIRC] > > > > Hmm... baby brain? > > :) > > I think I only mentioned it in a private mail at some point. > > > > > Sorry about that. I've been a bit useless lately. For some reason it wa= sn't on > > my list, but its there now. Will prioritise it, because I agree it's no= t good. > > > IIRC, if you do > > echo never > /sys/kernel/mm/transparent_hugepage/enabled > echo always > /sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enable= d > > khugepaged will not get activated. khugepaged is controlled by the top level knob. But the above setting sounds confusing, can we disable the top level knob, but enable it on a per-order basis? TBH, it sounds weird and doesn't make too much sense to me. > > -- > Cheers, > > David / dhildenb > >