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 55587C021B8 for ; Wed, 26 Feb 2025 18:55:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B181228000A; Wed, 26 Feb 2025 13:55:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AC7D4280008; Wed, 26 Feb 2025 13:55:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B74628000A; Wed, 26 Feb 2025 13:55:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7C2BE280008 for ; Wed, 26 Feb 2025 13:55:17 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 298BA14061C for ; Wed, 26 Feb 2025 18:55:17 +0000 (UTC) X-FDA: 83162998674.01.032806A Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) by imf28.hostedemail.com (Postfix) with ESMTP id 7485FC0008 for ; Wed, 26 Feb 2025 18:55:15 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Xaq6sBCj; spf=pass (imf28.hostedemail.com: domain of 3kmO_ZwsKCJs57F9MG9TOIBBJJBG9.7JHGDIPS-HHFQ57F.JMB@flex--ackerleytng.bounces.google.com designates 209.85.216.73 as permitted sender) smtp.mailfrom=3kmO_ZwsKCJs57F9MG9TOIBBJJBG9.7JHGDIPS-HHFQ57F.JMB@flex--ackerleytng.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740596115; 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: in-reply-to:in-reply-to:references:dkim-signature; bh=pMxjrmr+C2lqhTDO1AsbIyjKpGntAjw/Nw4lGuuG6FA=; b=gYn0mHDpoK3jFfxrZ/LmowY9NvcQncQiInbEuhN0xFj8crqHlVWcdkHfuymScqfCAsZ87w MqJgdlb9ARuaLQqrzQP2jJNrizlK6E3CcYGkvlG0vSFuo6lYfkKq52C+dYeAYY7N0+z7dQ gT0R0gsdWpe4zCINPsc4hO/GSUmaNHo= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Xaq6sBCj; spf=pass (imf28.hostedemail.com: domain of 3kmO_ZwsKCJs57F9MG9TOIBBJJBG9.7JHGDIPS-HHFQ57F.JMB@flex--ackerleytng.bounces.google.com designates 209.85.216.73 as permitted sender) smtp.mailfrom=3kmO_ZwsKCJs57F9MG9TOIBBJJBG9.7JHGDIPS-HHFQ57F.JMB@flex--ackerleytng.bounces.google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740596115; a=rsa-sha256; cv=none; b=Oex9o6aM1bcIL+zRvMCbW5vvZbGoxMGlMPt4dNOKydWiTGHq8B/MBAEWjRtcGouKZzFNTk 9PeMi0zBuhRp+l8EHgmcMJwLECpzdii+E8woGJZS+S6WpBWEFKvvfwEcV3ShyX2SLi1Dbh Xvu2f4uasoRrO60TOJRzNsEkQf7mbo8= Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2fc2b258e82so335062a91.0 for ; Wed, 26 Feb 2025 10:55:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740596114; x=1741200914; darn=kvack.org; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date:from:to :cc:subject:date:message-id:reply-to; bh=pMxjrmr+C2lqhTDO1AsbIyjKpGntAjw/Nw4lGuuG6FA=; b=Xaq6sBCjbjH1miBaJpw7PQZrP40cUw/4ZmckcLHTl2t3GQUrtY1oZFG35e1+cMeZT9 Nl8Im/8kp1+pnDVRkYNIOiA8MJbt3mn8I2rHaKwK9Rlw8rGgJ6mw0WSk2gTYyy2OBt0r RFYBl6qlcwPR6YBkRKJRI6rlSSuA2uGEQgLIuTKLZcV/NYpYFfFZAHay2CwyOXhjzgs8 ogQ+3j/ivGIofx66nhHgs99IAcjwEJTD2PKXf5FFj1CY+lDxQ043cxK6GRvcBFhEAbeD 7eVeg6NqTyW8s4swUWih+0x7MLt2KOpGmelV0XWn+cyqgivGBT0vx7CT3HA8tvdmDzHn C0Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740596114; x=1741200914; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pMxjrmr+C2lqhTDO1AsbIyjKpGntAjw/Nw4lGuuG6FA=; b=LWH5fD/g2AH4JNtKxhBE4v9jOKEmr67usmRyD8cxclxttk7vO8/h1RdUmEabtksXme VghAOcvfwOSAGW0GxWoocrkfvQNuzb5k9wiESAM4h1+px/RR3fnF3XOxx6P6Ktl0r5g0 AwfUG55T08hCTU1a0LyAZUHN6W8bGFwYhrM8pG1nJcoHgjmr2GyAIzWhkAF4txWUcoXU tgJ1U4YU+ghFoPwkgtElExwMY7H9CIFbWe9Bj2r8R3Ha7NgTnK9fE7YP+iy+9/4NO6g8 qMkl2kGNCAjnqHrrWJymVhphenULVq6oyRJFn+NGzdJVxTJaf+5+uCldXqvILN+31sGM /O8w== X-Forwarded-Encrypted: i=1; AJvYcCXhRjO9nZtdgKojAJTpf9gIpXerR7A5WPe6LvokFmEQCCV3+6fONLkPuR9wQY/4KfFKpV735vQ+nQ==@kvack.org X-Gm-Message-State: AOJu0Ywnw7UVULadIpS9a7OY7YQ1phO+ryjk0a+C5AYhB1eraPJ/H40N iEHPpahKSoreiIyMI/inI+8rTBb5AimZQCKsWrtW1iT8mguN1c6f5BaGCKhCZTa59V4MhAI6kl1 sCdWhj1l+Nmj412gjYsquqw== X-Google-Smtp-Source: AGHT+IHXoYciUWfZJpCpSwX24N+e+ntqta9etAMpkRTScD6zTBwVRDGyD1SA1Qg0PQJM6OFM5du14J4bw5ZP8rzFVg== X-Received: from pjbqi7.prod.google.com ([2002:a17:90b:2747:b0:2f5:4762:e778]) (user=ackerleytng job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90a:cf8e:b0:2fe:7fea:ca34 with SMTP id 98e67ed59e1d1-2fe7feaca86mr5657943a91.32.1740596114259; Wed, 26 Feb 2025 10:55:14 -0800 (PST) Date: Wed, 26 Feb 2025 18:55:12 +0000 In-Reply-To: (message from Ackerley Tng on Thu, 13 Feb 2025 09:47:33 +0000) Mime-Version: 1.0 Message-ID: Subject: Re: [RFC PATCH 14/39] KVM: guest_memfd: hugetlb: initialization and cleanup From: Ackerley Tng To: Ackerley Tng Cc: peterx@redhat.com, tabba@google.com, quic_eberman@quicinc.com, roypat@amazon.co.uk, jgg@nvidia.com, david@redhat.com, rientjes@google.com, fvdl@google.com, jthoughton@google.com, seanjc@google.com, pbonzini@redhat.com, zhiquan1.li@intel.com, fan.du@intel.com, jun.miao@intel.com, isaku.yamahata@intel.com, muchun.song@linux.dev, mike.kravetz@oracle.com, erdemaktas@google.com, vannapurve@google.com, qperret@google.com, jhubbard@nvidia.com, willy@infradead.org, shuah@kernel.org, brauner@kernel.org, bfoster@redhat.com, kent.overstreet@linux.dev, pvorel@suse.cz, rppt@kernel.org, richard.weiyang@gmail.com, anup@brainfault.org, haibo1.xu@intel.com, ajones@ventanamicro.com, vkuznets@redhat.com, maciej.wieczor-retman@intel.com, pgonda@google.com, oliver.upton@linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-fsdevel@kvack.org Content-Type: text/plain; charset="UTF-8" X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 7485FC0008 X-Stat-Signature: y4sj6i51c13nzu1ktf1baqonok391m1s X-HE-Tag: 1740596115-338331 X-HE-Meta: U2FsdGVkX1+cGbN3LRfy+xtsqh1/FcUPZc9H2L8Qu+dE0EwIr5SdKmor0Z6JwMQqDoFfo5PsDPnnVe3w2STcCOY8RDBGJcBCCkhEdZjNHvWpNdwq8kNtopSChy0F1rFWIlNxF1J3RU71mQRV5eWOOP5rj9Y1r2DG8s/An4W4uj1J/kUzD+0p5xAAQgnzS3pTNHBV8wo2rQd793xBfDB6qu3pKJr2bXC4sMTHpsGH3IMbse3XY4axBbXXh1td/Ab1faoNzstI4FNOQRrFQpYFL48prblppAuH4lQm97jXDtlTTun/QpY9xSJ6saJG+EIKQ1cBQF3f4MH6whuzoq6mEVxE4XursrMVrlIeEeRo4I2QK3lP8Crdbl/KJny9p6dYA/XD87WAmDJK+YKmeaumgfKof9oYoUUBV3EAopEkKndCUY8eHo24p5ASihl+fiDEZ5EZ3jqyqKZeujxjCHXakTcLNwwDgXYSemILilDBMS1LN1r8xtV4bfHCQcDBNrhMAMzJo3AljS5mWgo/1x347G3XgAZUmsJR9TLNdGJGElP53TZP1Q+DMfcxo0uwG5l+TrrDUX0PwSUA43j8tjqvVwJr6SkPzDuYBUhWVDggVawHMKK6GQfLwLyaC8fZUJIaAL+vu7tIElro+kqmP0bETl6f+/ca9l35Mg3jsWyQBLofnyx808TRUU5GMoC6hXCYBdZjnKtW2rn20f3cgVen/dkBW3l8qvcWcs1d9tEXINTPfvFBByFqVr7RRanx0eJgPexd7JmnF0KbtibSwdRIOcDYp7jn01znPNybB8oRy3yiMJstsp8JxZTaxGrTdevwGuRBqHzcB5MizRjzuL0PEtZDYX2xmEJt8qUnClOFpXQBzjDdDoILS5qKDpk1DzlIMfNSp13cxt4h2QrlWvPA+YXZlcYcleDshKJip7b+yzhQG4l7VUPdqnPSBHgdk9D8lLS6ukPVqJvkeCpP2M0 AT9Uj1gI l06C3KtxCWCq/ZfvUBL+HFYtPAw9vSxi+4RX4DvlWEK2XSOgGkHavoa1dohr45xOQVxEEMUQ4tI9K4ZdCxNnYVmZnCG9b3xnni1ZNtUOoHVEh8YI2etAfGeWy7g76+3Jz8zzYW3sDdOTI9nZ6ZPWXBLvEs/Y7pjXOd7jcCWBG8/nzAwheibc3MqXgmpRLDN7MqqI6mkP5xSNoi3/2xuJX7QOJn4W82ihozgcbbbH5cVkCrs4tZehZcAzgyY1PGlEeSepuF4mIthkhu0Qcj1xRer/cpBa5sRrCSxfWBRAAn/0WLT53O+V5l/rJrWbH+1OXwTFYqQGFfg2QyCYXkktlEepk5HUAW4ZAEjrajHvkLwkLeLhPKTqhA7XWSVxBP3j/9DpqWub1jpywWjz5bMRRFQfoi9I8WpHhDNgxTjQ7w0sJEvjrxXqHYct6V0aJ0tZGdw1Rxz+tTlRN3xcNpDM/ufYZA/V6yKeOjvwtlz573h+qO4Bxgdkp28y9dD1ac/5AN2y5kCmaB1p4P1TJHXssA8l2E6416VGfVhVAwURHS62J0jY2w4WSWXu5hgV6LzpAO54qLan6uY1zq9SjIocJbo5BY2d9TWd38W41o3zIKvLeG+WTKlJbp05yMgIVJmz56Q8FMEAd4NBoijXqbh/F9dbyPnnEEWBAyf8umVDhVzTvW6X+1xszXr0VdPFZC3LvENJcoLo99bLEV+o= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000006, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Ackerley Tng writes: > Peter Xu writes: > >> On Tue, Sep 10, 2024 at 11:43:45PM +0000, Ackerley Tng wrote: >>> +/** >>> + * Removes folios in range [@lstart, @lend) from page cache of inode, updates >>> + * inode metadata and hugetlb reservations. >>> + */ >>> +static void kvm_gmem_hugetlb_truncate_folios_range(struct inode *inode, >>> + loff_t lstart, loff_t lend) >>> +{ >>> + struct kvm_gmem_hugetlb *hgmem; >>> + struct hstate *h; >>> + int gbl_reserve; >>> + int num_freed; >>> + >>> + hgmem = kvm_gmem_hgmem(inode); >>> + h = hgmem->h; >>> + >>> + num_freed = kvm_gmem_hugetlb_filemap_remove_folios(inode->i_mapping, >>> + h, lstart, lend); >>> + >>> + gbl_reserve = hugepage_subpool_put_pages(hgmem->spool, num_freed); >>> + hugetlb_acct_memory(h, -gbl_reserve); >> >> I wonder whether this is needed, and whether hugetlb_acct_memory() needs to >> be exported in the other patch. >> >> IIUC subpools manages the global reservation on its own when min_pages is >> set (which should be gmem's case, where both max/min set to gmem size). >> That's in hugepage_put_subpool() -> unlock_or_release_subpool(). >> > > Thank you for pointing this out! You are right and I will remove > hugetlb_acct_memory() from here. > I looked further at the folio cleanup process in free_huge_folio() and I realized I should be returning the pages to the subpool via free_huge_folio(). There should be no call to hugepage_subpool_put_pages() directly from this truncate function. To use free_huge_folio() to return the pages to the subpool, I will clear the restore_reserve flag once guest_memfd allocates a folio. All the guest_memfd hugetlb folios will always have the restore_reserve flag cleared. With the restore_reserve flag cleared, free_huge_folio() will do hugepage_subpool_put_pages(), and then restore the reservation in hstate as well. Returning the folio to the subpool on freeing is important and correct, since if/when the folio_put() callback is used, the filemap may not hold the last refcount on the folio, so truncation may not be when the folio should not be returned to the subpool. >>> + >>> + spin_lock(&inode->i_lock); >>> + inode->i_blocks -= blocks_per_huge_page(h) * num_freed; >>> + spin_unlock(&inode->i_lock); >>> +}