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 8E3B4EE01F0 for ; Tue, 10 Sep 2024 23:08:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BAD4E8D00C7; Tue, 10 Sep 2024 19:08:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B5D7D8D0056; Tue, 10 Sep 2024 19:08:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9FDDE8D00C7; Tue, 10 Sep 2024 19:08:36 -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 81B968D0056 for ; Tue, 10 Sep 2024 19:08:36 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id CDA8F160CA6 for ; Tue, 10 Sep 2024 23:08:35 +0000 (UTC) X-FDA: 82550369790.30.1FAE149 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) by imf02.hostedemail.com (Postfix) with ESMTP id A02F380007 for ; Tue, 10 Sep 2024 23:08:33 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b=UkBHhW82; dmarc=none; spf=pass (imf02.hostedemail.com: domain of axboe@kernel.dk designates 209.85.210.175 as permitted sender) smtp.mailfrom=axboe@kernel.dk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726009630; a=rsa-sha256; cv=none; b=PRJiVisUTpo7LLECk1qWefgLcNC3gg7g+mPoaOUh7auV+NziJgjd7dYXsTlkBCHGrt79op xDtRgQgL6oBCmnsfowIYum/OtOS8Umt98hvH12EnvIUZioWXZhx11TsZ5KTEQamxs8wxkC DN4Cy0NV4bT9BXS3gvghpIiwVVvPn3c= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=kernel-dk.20230601.gappssmtp.com header.s=20230601 header.b=UkBHhW82; dmarc=none; spf=pass (imf02.hostedemail.com: domain of axboe@kernel.dk designates 209.85.210.175 as permitted sender) smtp.mailfrom=axboe@kernel.dk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726009630; 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=IB5YGRSFIkPWzaMg9/hIud2kLZrnZBM+/JHnL4w8ZiU=; b=kK1oRebWGhUXrjt2JxqvfQHg1G2EmAjsiutsIkyr1Z9V1wItc5p2OoSX5JuhNbXANxmMUq suamy1jIIjNaXtyb8zs6IcKJmcyZBx4G+7u89W8oJQSqlHXsISOv1PCfyHMComK8haOOwi O6Lea9jsOyU3+5RLtvislFXe3gLgraM= Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-718e3c98b5aso2850833b3a.0 for ; Tue, 10 Sep 2024 16:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20230601.gappssmtp.com; s=20230601; t=1726009712; x=1726614512; darn=kvack.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=IB5YGRSFIkPWzaMg9/hIud2kLZrnZBM+/JHnL4w8ZiU=; b=UkBHhW82/AIg2yVMeo2AZo6yMNnDeAfPNq92HEOLG3uer9xqgyV9i/Zenync7cw7CW 8hPeeVjEMaL52hcKi027a4snruGzDJGBo8gdb15UAaLlfeTQqwRhWHkkLx2HWKe5i7HO j5XmQKtCpMvIkKtl7CfqMwF1Y1SwWm6D99wCkDTvRcQQwxLchFubieCteB960JyFyjRg LBNuP0ISlTy5g4/wbExgUpwEm9cNaLE3aOsK30yCbFRtBBvKWD8Pxx0ZhfumLKCahC81 r8bWMlX3Cii5gM557iHmpD919iiI7SIWQdCg2jhc+5yCpUyDNe10xjtNhtSMD++oHKYY 1doA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726009712; x=1726614512; 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=IB5YGRSFIkPWzaMg9/hIud2kLZrnZBM+/JHnL4w8ZiU=; b=uI8yiG3dPZxLkrYlojFfciEkrcTsanNZCGWdVHYxwj14Nwvk4SxHEA3B8mzqKOp5d/ UQlX/lwNH4vDB9v1h9uM2owmIuqpJ4fcD37RH6EDVUdPP9qxvziwkfI+spBpWdG4SwpR 3X1qoPVLE7MtyJ2Lt9nknISA27Bdu0kASV3G9PKwheC82lX2KEzv6zpKhzKKrufCKa7v OZWfJvDYl4fzX3V3NdfQTRbYeKYsyNT/iqLsVObKvJRBQEqlMq7KvG0ONyssChWrwQRY ZnQPoQNoRLHej7AvVa9OyOlyZF4ILsxPIwmFNCg7kAzetPEq2GXqmTtxSjYFGOoMh0Gt OC8A== X-Gm-Message-State: AOJu0YwL0E6kUHn6uYJsacNsoMKmrGgSq/P/71RuNUofc0Q/Uxm4geb9 ZpuR+StYHo7gWyxm8EZQxDLuOF0UQ07gI2G5vsrAKAJ2BERUBczGczd6wypo1RU= X-Google-Smtp-Source: AGHT+IHaG3rWatnbTD92tNjdHA+pk2YeqQB3g2ZgIJg/H3QzbhnYjLnE2tlQBjFkmOB2+SJXN45htg== X-Received: by 2002:a05:6a00:4651:b0:70d:3354:a190 with SMTP id d2e1a72fcca58-718d5f1f833mr17157922b3a.27.1726009711876; Tue, 10 Sep 2024 16:08:31 -0700 (PDT) Received: from [192.168.1.150] ([198.8.77.157]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-71908fc851dsm1926742b3a.14.2024.09.10.16.08.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Sep 2024 16:08:31 -0700 (PDT) Message-ID: <9a924b36-aea7-4492-912a-a7ab4f2cbb96@kernel.dk> Date: Tue, 10 Sep 2024 17:08:30 -0600 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Hugepage program taking forever to exit To: Yu Zhao Cc: Linux-MM , Johannes Weiner , Andrew Morton , Muchun Song References: <02ffa542-ce49-4755-9d2b-29841f9973e0@kernel.dk> Content-Language: en-US From: Jens Axboe In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: A02F380007 X-Stat-Signature: q8ibne1dg131j5hokm5h3zurdjzwc3az X-Rspam-User: X-HE-Tag: 1726009713-40672 X-HE-Meta: U2FsdGVkX1+USqQqCb91+utROhmrvuBU5efYxSIKTWtSr7rUZQE9t5WqGt38Y+olhwMv6yFJonBSXXy990ifj2ukzcT0soN/tgaA6wHou2HPhbYibx9V7rJ4ESctfGfT9J/0HYulHSsSp3b3/vhUnGFxlmXAw7v+v3Y3k1VXpTzzbjRYcjCZUaQOZa9wItyImLum8+BxRqpWQqc6effVahDY5mJlwpnxPZwmkrf8mu+0LpVyj08THzjdsVolms7NuVuPMN3FdXsas8WjLGRCPG0h6aioxNfV8XaN6iWb4noHiuhsWG+mfQcww92TvrOKoeXOx1pnsWZ3CAzfS8Voat/0NJrYSy4EYb5f7ep2doS/vFCt4/GXg9Wev/Kvjo+bCi6Q1SvpEWzsHAUKEy6X5NrFfHNUMxQn3bIhHicmSPBc9NfXE/huXice7vxXEzuvR3NTyk967crWee4vOJ6Xm6lnkyeDee/dUf7tkZybQa+LCbAV9nVHF3fKrX7f/mgidtTrEPV3FCY3/h7KlhmOub/5KRaQybycejMYLBuEXguU9VB+FWjjGAa30p2uN1a4gCBv6ZDmr36Z6i5V+hYvHkqCw1MKeMJVumjg9rY+C3mAN+zV6PoZ9BL8N/O56E9uOsa31UsJJ97bQUl0vZzSj9TjlySeYxFXY9K3Z6DLYg2T18wwXozYFELlr1EvaCihnhE1MT/ck/kNR5ijCItFWb1Rkrpdnd6BmzDst1UhqMLBdjl5ODBo+x/IyXjatwE+gbfMH2P7Xb7V28Hw4mHGgAe55sVcJ14nE1PajuLyHdYGHN6dzVH1jnXbkBXTyvTjxKAE82lI3Q8dlJdNhIIzx0FA0zOaIXyLdxS67cIIYjZhvh2N251VPiAri3a9kdeafVtw7I1TIyMrggvw2pd+FcIpT39Wvldba7twluZOnnqdf7MqTdk5aLEHboXypl2AQiHXdoyAV1XId3kTdTp 5ukz6nXC plzXnrVFCf+t3kZkCUpE6fWwgPmYnVNwqt/dF+9bIZ4WYKSkh36DjPSJ2uNn8U5CXTS6EiUKXziBKpuxvXn8SCq2nCTrqI5ovmz/rFIlBbYWg6wn/Fjp4mFLX1STU9XoT3gldz8Cj68ozmvz9PQVKSOLTD2xxwnYifh/YCdMgKKBKETfALA4oteB5Y1vKJdngJ0Dm51z/aoLmu/2yhhfjTNolNlmWp7VJECP7CuaVx0eKripSlvdT3QwC3rlo+gpVdGaLrDpbc0r0wFmYjWJhZU8BoXdShX328iM4i88slCwxpSKNfgYBArZ8zQHpn8nG9U7g+3h6vYCWlUkcssr+Oi3BdM0JACZsdQpy+nCO/7qp+pvRph7YMWuqCwYw/9lN10R6SURKJC1vpmo= 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 9/10/24 2:17 PM, Yu Zhao wrote: > On Tue, Sep 10, 2024 at 12:21?PM Jens Axboe wrote: >> >> Hi, >> >> Investigating another issue, I wrote the following simple program that allocates >> and faults in 500 1GB huge pages, and then registers them with io_uring. Each >> step is timed: >> >> Got 500 huge pages (each 1024MB) in 0 msec >> Faulted in 500 huge pages in 38632 msec >> Registered 500 pages in 867 msec >> >> and as expected, faulting in the pages takes (by far) the longest. From >> the above, you'd also expect the total runtime to be around ~39 seconds. >> But it is not... In fact it takes 82 seconds in total for this program >> to have exited. Looking at why, I see: >> >> [<0>] __wait_rcu_gp+0x12b/0x160 >> [<0>] synchronize_rcu_normal.part.0+0x2a/0x30 >> [<0>] hugetlb_vmemmap_restore_folios+0x22/0xe0 >> [<0>] update_and_free_pages_bulk+0x4c/0x220 >> [<0>] return_unused_surplus_pages+0x80/0xa0 >> [<0>] hugetlb_acct_memory.part.0+0x2dd/0x3b0 >> [<0>] hugetlb_vm_op_close+0x160/0x180 >> [<0>] remove_vma+0x20/0x60 >> [<0>] exit_mmap+0x199/0x340 >> [<0>] mmput+0x49/0x110 >> [<0>] do_exit+0x261/0x9b0 >> [<0>] do_group_exit+0x2c/0x80 >> [<0>] __x64_sys_exit_group+0x14/0x20 >> [<0>] x64_sys_call+0x714/0x720 >> [<0>] do_syscall_64+0x5b/0x160 >> [<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53 >> >> and yes, it does look like the program is mostly idle for most of the >> time while returning these huge pages. It's also telling us exactly why >> we're just sitting idle - RCU grace period. >> >> The below quick change means the runtime of the program is pretty much >> just the time it takes to execute the parts of it, as you can see from >> the full output after the change: >> >> axboe@r7525 ~> time sudo ./reg-huge >> Got 500 huge pages (each 1024MB) in 0 msec >> Faulted in 500 huge pages in 38632 msec >> Registered 500 pages in 867 msec >> >> ________________________________________________________ >> Executed in 39.53 secs fish external >> usr time 4.88 millis 238.00 micros 4.64 millis >> sys time 0.00 millis 0.00 micros 0.00 millis >> >> where 38632+876 == 39.51s. >> >> Looks like this was introduced by: >> >> commit bd225530a4c717714722c3731442b78954c765b3 >> Author: Yu Zhao >> Date: Thu Jun 27 16:27:05 2024 -0600 > > Fixes are in git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git mm-stable > > c2a967f6ab0e mm/hugetlb_vmemmap: don't synchronize_rcu() without HVO > c0f398c3b2cf mm/hugetlb_vmemmap: batch HVO work when demoting > > Additional improvements from mm-stable that may or may not help your test case: > > e98337d11bbd mm/contig_alloc: support __GFP_COMP > 463586e9ff39 mm/cma: add cma_{alloc,free}_folio() > cf54f310d0d3 mm/hugetlb: use __GFP_COMP for gigantic folios I didn't pick patches, just pulled all of mm-stable - yep that fixes it for me, no longer spending 60+% of the runtime during exit. I trust these are heading to stable? -- Jens Axboe