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 1702DC5474A for ; Wed, 28 Aug 2024 03:51:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2B916B0088; Tue, 27 Aug 2024 23:51:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DBC66B0089; Tue, 27 Aug 2024 23:51:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8CBB16B008A; Tue, 27 Aug 2024 23:51:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 718266B0088 for ; Tue, 27 Aug 2024 23:51:40 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id EE08981C73 for ; Wed, 28 Aug 2024 03:51:39 +0000 (UTC) X-FDA: 82500279918.05.6D63576 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf06.hostedemail.com (Postfix) with ESMTP id C055B180004 for ; Wed, 28 Aug 2024 03:51:36 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ESC3wDKZ; spf=pass (imf06.hostedemail.com: domain of mpenttil@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=mpenttil@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724817009; 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=X9VpCH4mmRGV8sop8sHJluqGfyo7L8s9UgztsPfGWBM=; b=Vcd3zqOiQzQVcwUGJUPoJvxRRkS2FzFi6AHxfH6XCZTVl5OebvogVvbAte6edhaP5xBaXi 86KOLTSXxsj/h5ik2iS0AVfVABsYySoxcRBlk7JR25XO/uNWCScX4u2OO1oogEoYjzsE59 Hw2PTZ/gTfpezaJR52fetXh8A/wWHdA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724817009; a=rsa-sha256; cv=none; b=BY8dzpzdoaa/mFRujd+csrqaAvqHDq+tbYhXn23R919c5mYV/9O1hHjI5LLJ29LscXsnC2 8MH8siT8/+1wRDSI1ArAz17NFcVAoU/E3Y0TbWWYiDNxyQf9u/fnh86pCmtDBmW5iw1rIT AIAUJbo77N8zH9z/JWJsbOw7c6AkftE= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ESC3wDKZ; spf=pass (imf06.hostedemail.com: domain of mpenttil@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=mpenttil@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1724817096; 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; bh=X9VpCH4mmRGV8sop8sHJluqGfyo7L8s9UgztsPfGWBM=; b=ESC3wDKZBvo8638xdZgjXz8Rao/jcVl7/dd/yQ6xphNYzpY7wiDEO7tX4bcYAccRYO9Y4f Hg2R1EOLCu3O8lWvfREAWJiPgMkY8u+0GKUfofI53g5igB3hawySLDB7xLCDKpMdrESG5X P3BE5d+28PZ/PfOeO26Q6vKZMeAR2Ew= Received: from mail-lj1-f199.google.com (mail-lj1-f199.google.com [209.85.208.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-682-3vlanzIaOK-6E2Z-D468IA-1; Tue, 27 Aug 2024 23:51:34 -0400 X-MC-Unique: 3vlanzIaOK-6E2Z-D468IA-1 Received: by mail-lj1-f199.google.com with SMTP id 38308e7fff4ca-2f401c76ce1so63207091fa.0 for ; Tue, 27 Aug 2024 20:51:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724817093; x=1725421893; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=X9VpCH4mmRGV8sop8sHJluqGfyo7L8s9UgztsPfGWBM=; b=s771PYsb1IluCOvNF2bJZ8D5BvV/k77lB2S8k3ohZ7iqfIDnGZkcmSMUkrufTWkGMa hnHO+kYMB3Vw6kLc4HfojWMcm976/T18U6h90+jdSMDpo3r/bzBFiGtZBfZJnkOx5/tF gqrofcHM1mI3wH4uNTLWZgYT+fFQbQW6DsRpX9D+82+e9sioNgq+kpOXW5oP3WNSQh84 N7brt8Iogfio+Cqy/oM4pw126A7LY9RL2SlJw4vAMWM+3Sx7UY9aU7IkXrQ0CArZyI7B SyGNAp5fCcpBzR83kThYRcRqaJZb68Tr8VKgOKNSTQgRTi5Qw5EUSyQ5MlxhCTFFw6Xi PXxw== X-Forwarded-Encrypted: i=1; AJvYcCVm7U326wJ+rjuWyo6lRolgPNa14n1cTeJMVHrF9rpOBv0OofWpSphhaQxxtaaVHlYONAT6RfYT9g==@kvack.org X-Gm-Message-State: AOJu0YypYVZMxGbhFZ7fZpUWz4g0smqfsv3uleB/RgAuUyXlktdNBcn6 oSNK22Vfs8+phqz59/BBhPG1PiJcc7IH6Fg+KnTWpxkaaBI7POH0YdEJYyhbQblEgCbeixrWkBh U1k8jO6k1AzDSAknSGLBOyhwNxGwdle4oKHwGyj7RrWJscOs= X-Received: by 2002:a2e:a168:0:b0:2ef:17ee:62a2 with SMTP id 38308e7fff4ca-2f4f574f76fmr112604151fa.14.1724817092580; Tue, 27 Aug 2024 20:51:32 -0700 (PDT) X-Google-Smtp-Source: AGHT+IG7+IV46vQ8pctb7YqbUkP1jVndBl0vdjs0DAHSmhRtspCou0VwevbaM/BtwVuQWg609keFrQ== X-Received: by 2002:a2e:a168:0:b0:2ef:17ee:62a2 with SMTP id 38308e7fff4ca-2f4f574f76fmr112603901fa.14.1724817091605; Tue, 27 Aug 2024 20:51:31 -0700 (PDT) Received: from [192.168.1.86] (82-181-87-79.bb.dnainternet.fi. [82.181.87.79]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-2f4047dcfe3sm17731291fa.56.2024.08.27.20.51.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 27 Aug 2024 20:51:30 -0700 (PDT) Message-ID: <25d25633-0bf4-452c-b665-354a5aaa5d0c@redhat.com> Date: Wed, 28 Aug 2024 06:51:29 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2] vma remove the unneeded avc bound with non-CoWed folio To: zhiguojiang , David Hildenbrand , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, oe-lkp@lists.linux.dev, oliver.sang@intel.com Cc: opensource.kernel@vivo.com References: <20240823140139.263-1-justinjiang@vivo.com> <2f19c2ff-66b2-4860-a870-a1bffe73320c@redhat.com> <1e95a6e4-9993-40ae-b563-44b7024da25c@redhat.com> <5b56e76b-cf73-4cfd-b4c5-03fdece234fd@vivo.com> From: =?UTF-8?Q?Mika_Penttil=C3=A4?= In-Reply-To: <5b56e76b-cf73-4cfd-b4c5-03fdece234fd@vivo.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Stat-Signature: n1xmk498o64oneij4g94s97d3jz95q7a X-Rspamd-Queue-Id: C055B180004 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1724817096-108359 X-HE-Meta: U2FsdGVkX1+793WlgO8wfNRaEItZuBSSWVFydZ85DUAfRySmpMP+8UNCj4lF8pFz6kjjuCLGcMwf/omTtWagU8Vx9QWr5o4V6H6HXVRRdJIrBoLw8o1OTMqe8umw6OaYjoRT2Yd8sIeOSTWijucYwYys/Erpe6kA7pYiDFWEDLrn9jxK0XJaoHMkW8NssxRkvdqu6Wao+9iZVg0g1XxWhOoMLb7DqBfK09W9SD95Fj0+BpjAqkasxoz6MMQ9zkPeoHI6ct3ATse7TkTwmlA9QJew2fvHYupEVFG1YYU0EaW5V6jMgNX54nSz8Eq7SSFWbJ7eJ+B+XlwYtV7fV0PfPuxyKWH075xiyQy/M9sVR6OXKwYPNYuz916viWqZJ0PJkV+t9MtqtE0TByDiPAvQGUa6vblscAJ9M48Gg4/krK7iTrI5+CPuFMzdHRHYXXGY4z+eFJQKkBHZVv+SMXWXSOC+BalIA0zik14POJkWxAAAwZ1oa6CGzKrgQSaavebLlpum9R4PoCK+V0UkPx4s4XAnCorQ4T7pa72gddk/XzutYxPLCsQ9y2ssbYwpHp3rClx7FaZ20R8Tc/Jomt7cfg/YFQS4q4lsuXeRiwNK8Ba93NyHtkmdtLaXpQl7ByStTWRngd8pjnnwSMJ6t3QOxGzpLqrK21ughCWGUzgR2EkLlgCUcduJ5U2EA1ES2Jf5v2XLdOi/+QhlffHMQGrcwyvf72pETl/M8blsFUIwF7cRn+L+l7dKvC4yEapgZ31+pWn0L6AaVcdlHoIUQIMZmOJCDil7zAzHSJawCyXGeZYcZPwb2tnFPUfN09Ua84IxPzYhNNmhQbdl+UZThPHTAud9OPs5rQQpYMEHRWiGG7jqW20d0P/pz2s+V6lYFdiFmREDfCND78Lyqc0HZ5evGQyhBIj70ij1cMRQzEviFDTybbN08AFJ8gLc1gUUww1A+hPX3hpWm8iM0saDKCi h7ZIfsXu 8q9fIh+pn8pmAgoMJYZ0Ck9cLUshfKjJKxcDqcdlLZe6ylxnQyPUBJIxqk07Bsbf3ZZlfqltHBrQd44pPWLsCrJ7k3EdEMOC3pqejk+01fL58boiGIfQVtfAGS5dB9uwdHKvWxM0hHK4tjgNP8nB8MrjbMjUCHqaFXOQS9klyhpKbysfwcXCmvtYwyWbfbXJdZH5+HbJxYaszMwJgPwSb02XOhpsW/vOYbBZFCl7lmraBHACB6ht5wop+A96+ingqhpJmwfLloiH+wIdisv3Di2eJ0THqO2b48/AwmM/L7VGVnodPblRWiQI5cerXBjn2B8CL0sKdZxiRtWFybeJGXm1dKuQbEB+myMtjMD146bKVg5e/qzUUgVde8fgq7dHdWyG3bKR4ASTfT6HkxaL4C9UkN0kMQrLAMqdL0XF2XEd8Ehdp/cLqnmr1fwOFvA4N7ngAm1Jy8KNPoj1veazYhH95tra0PM++3QYyfKfYYk1e9zYvKErD+jPAyvDzhcsb205mtfZ6wtgfXwCf+fIzPHqkFOtALIH/i4I9JSiQ+mCavi79dP3R7WwK/uAE3qeZrjBS 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: Hi, On 8/28/24 04:14, zhiguojiang wrote: > > > 在 2024/8/28 1:35, David Hildenbrand 写道: >> On 27.08.24 03:50, zhiguojiang wrote: >>> >>> >>> 在 2024/8/27 1:24, David Hildenbrand 写道: >>>> On 23.08.24 16:01, Zhiguo Jiang wrote: >>>>> After CoWed by do_wp_page, the vma established a new mapping >>>>> relationship >>>>> with the CoWed folio instead of the non-CoWed folio. However, >>>>> regarding >>>>> the situation where vma->anon_vma and the non-CoWed folio's >>>>> anon_vma are >>>>> not same, the avc binding relationship between them will no longer be >>>>> needed, so it is issue for the avc binding relationship still >>>>> existing >>>>> between them. >>>>> >>>>> This patch will remove the avc binding relationship between vma >>>>> and the >>>>> non-CoWed folio's anon_vma, which each has their own independent >>>>> anon_vma. It can also alleviates rmap overhead simultaneously. >>>>> >>>>> Signed-off-by: Zhiguo Jiang >>>>> --- >>>>> -v2: >>>>>    * Solve the kernel test robot noticed "WARNING" >>>>>      Reported-by: kernel test robot >>>>>      Closes: >>>>> https://lore.kernel.org/oe-lkp/202408230938.43f55b4-lkp@intel.com >>>>>    * Update comments to more accurately describe this patch. >>>>> >>>>> -v1: >>>>> https://lore.kernel.org/linux-mm/20240820143359.199-1-justinjiang@vivo.com/ >>>>> >>>>> >>>>>    include/linux/rmap.h |  1 + >>>>>    mm/memory.c          |  8 +++++++ >>>>>    mm/rmap.c            | 53 >>>>> ++++++++++++++++++++++++++++++++++++++++++++ >>>>>    3 files changed, 62 insertions(+) >>>>> >>>>> diff --git a/include/linux/rmap.h b/include/linux/rmap.h >>>>> index 91b5935e8485..8607d28a3146 >>>>> --- a/include/linux/rmap.h >>>>> +++ b/include/linux/rmap.h >>>>> @@ -257,6 +257,7 @@ void folio_remove_rmap_ptes(struct folio *, >>>>> struct page *, int nr_pages, >>>>>        folio_remove_rmap_ptes(folio, page, 1, vma) >>>>>    void folio_remove_rmap_pmd(struct folio *, struct page *, >>>>>            struct vm_area_struct *); >>>>> +void folio_remove_anon_avc(struct folio *, struct vm_area_struct *); >>>>>      void hugetlb_add_anon_rmap(struct folio *, struct >>>>> vm_area_struct *, >>>>>            unsigned long address, rmap_t flags); >>>>> diff --git a/mm/memory.c b/mm/memory.c >>>>> index 93c0c25433d0..4c89cb1cb73e >>>>> --- a/mm/memory.c >>>>> +++ b/mm/memory.c >>>>> @@ -3428,6 +3428,14 @@ static vm_fault_t wp_page_copy(struct vm_fault >>>>> *vmf) >>>>>                 * old page will be flushed before it can be reused. >>>>>                 */ >>>>>                folio_remove_rmap_pte(old_folio, vmf->page, vma); >>>>> + >>>>> +            /* >>>>> +             * If the new_folio's anon_vma is different from the >>>>> +             * old_folio's anon_vma, the avc binding relationship >>>>> +             * between vma and the old_folio's anon_vma is removed, >>>>> +             * avoiding rmap redundant overhead. >>>>> +             */ >>>>> +            folio_remove_anon_avc(old_folio, vma); >>>> >>>> ... by increasing write fault latency, introducing an RMAP walk >>>> (!)? Hmm? >>>> >>>> On the reuse path, we do a folio_move_anon_rmap(), to optimize that. >>>> >>> Thanks for your comments. This may not be a good fixup patch. The >>> resue patch folio_move_anon_rmap() seems to be exclusive or >>> _refcount = 1 folios. The fork() path seems to clear exclusive flag >>> in copy_page_range() --> ... --> __folio_try_dup_anon_rmap(). However, >>> I observed lots of orphan avcs by the above debug trace logs in >>> wp_page_copy(). But they may be not removed by discussing with Mika. >> >> Was this patch ever tested? I cannot even boot a simple VM without an >> endless stream of >> >> [    5.804598] ------------[ cut here ]------------ >> [    5.805494] WARNING: CPU: 11 PID: 595 at mm/rmap.c:443 >> unlink_anon_vmas+0x19b/0x1d0 >> [    5.806962] Modules linked in: qemu_fw_cfg >> [    5.807762] CPU: 11 UID: 0 PID: 595 Comm: dracut-rootfs-g Tainted: >> G        W          6.11.0-rc4+ #72 >> [    5.809546] Tainted: [W]=WARN >> [    5.810127] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), >> BIOS 1.16.3-2.fc40 04/01/2014 >> [    5.811753] RIP: 0010:unlink_anon_vmas+0x19b/0x1d0 >> [    5.812680] Code: b0 00 00 00 00 75 1f f0 ff 8f a0 00 00 00 75 a2 >> e8 8a fd ff ff eb 9b 5b 5d 41 5c 41 5d 41 5e 41 5f e9 d4 82 d0 00 0f >> 0b eb dd <0f> 0b eb cf 0f 0b 48 83 c7 08 e8 16 40 d7 ff e9 ea fe ff >> ff 48 8b >> [    5.816247] RSP: 0018:ffffa19f43bb78d0 EFLAGS: 00010286 >> [    5.817258] RAX: ffff8a71c1bdd2d0 RBX: ffff8a71c1bdd2c0 RCX: >> ffff8a71c27a86c8 >> [    5.818624] RDX: 0000000000000001 RSI: ffff8a71c2771b28 RDI: >> ffff8a71c27a9e60 >> [    5.820011] RBP: dead000000000122 R08: 0000000000000000 R09: >> 0000000000000001 >> [    5.821380] R10: 0000000000000200 R11: 0000000000000001 R12: >> ffff8a71c2771b28 >> [    5.822748] R13: dead000000000100 R14: ffff8a71c2771b18 R15: >> ffff8a71c27a9e60 >> [    5.824122] FS:  0000000000000000(0000) GS:ffff8a7337980000(0000) >> knlGS:0000000000000000 >> [    5.825665] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [    5.826775] CR2: 00007fca7f70ac58 CR3: 00000001027b2004 CR4: >> 0000000000770ef0 >> [    5.828146] PKRU: 55555554 >> [    5.828686] Call Trace: >> [    5.829169]  >> [    5.829594]  ? __warn.cold+0xb1/0x13e >> [    5.830312]  ? unlink_anon_vmas+0x19b/0x1d0 >> [    5.831118]  ? report_bug+0xff/0x140 >> [    5.831840]  ? handle_bug+0x3c/0x80 >> [    5.832524]  ? exc_invalid_op+0x17/0x70 >> [    5.833262]  ? asm_exc_invalid_op+0x1a/0x20 >> [    5.834086]  ? unlink_anon_vmas+0x19b/0x1d0 >> [    5.834908]  free_pgtables+0x130/0x290 >> [    5.835661]  exit_mmap+0x19a/0x460 >> [    5.836351]  __mmput+0x4b/0x120 >> [    5.836965]  do_exit+0x2e1/0xac0 >> [    5.837601]  ? lock_release+0xd5/0x2c0 >> [    5.838343]  do_group_exit+0x36/0xa0 >> [    5.839035]  __x64_sys_exit_group+0x18/0x20 >> [    5.839866]  x64_sys_call+0x14b4/0x14c0 > Arm64 machine tested it and no crashes detected. You may try the > attachment modifition provided by Lorenzo Stoakes. Can you please > check if there are any opportunities for further improvement? This patch is still wrong afaics in the main logic, you can not remove the avc because the non cowed folios of child are not reached then. >> >> >> Andrew, please remove this from mm-unstable. > > Thanks > Zhiguo Thanks, Mika