From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A8E63194A75 for ; Tue, 7 Jan 2025 20:40:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282410; cv=none; b=Sn5N6VQQu6yE0hzG8hzXVNl2hcMArDF3EJwVSP45/7nZMZDcRuZQW8RvphVH61XY6ZAvXCgHT1MTJOhissMcHqbe/qfnTlrHrk48yfAHCFEItbs8llG5+mDlTKnPYeAd0mTk0kTRYsDgauT/bvPhWaNVYaSiik5U+QIbvcHY4xs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736282410; c=relaxed/simple; bh=IF+C1rFwvqnWfYV2Dt1BtsjYb7qogShJ7WtC0WritKw=; h=From:To:Cc:Subject:Date:Message-ID:Content-Type:MIME-Version; b=CgiqQihiYnshDRyQVVvBm21L7LbxYyBQgun6TCe0LMizG596eX03GyKw8FXvhx4qSFhz/6Sg7nrHoLLWTgrwbeLzBgonZ4YPwJZv+171rgyfe1RMryTo1d/soc0LdYxzXOlcrmYeFv3in8zby7O+bdPxyxnR+9cZUzmD9Da/OR0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=W0n/H4MV; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="W0n/H4MV" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736282407; 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; bh=oXSaxIGrBHbOX/JDeWthayCloueSD2Pd/sShB7OcJNc=; b=W0n/H4MV4YvSXYSrFJk+z2vlTOAWV/v/J9khmUtYNSvAjaQ2GPE0MZI84/P8TU2VwtjsDw lyyxwUuwjFRUPvcTGkCMWk8AxNtwP2y0YmInStGA2+HtOQCT9twfgslG4GcRCG212f3+j8 IpDjDG2QXHzVN5NSXpbqckWAjshbF34= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-346-O73frVHwNSuny4kQ7uXyhw-1; Tue, 07 Jan 2025 15:40:06 -0500 X-MC-Unique: O73frVHwNSuny4kQ7uXyhw-1 X-Mimecast-MFC-AGG-ID: O73frVHwNSuny4kQ7uXyhw Received: by mail-qv1-f70.google.com with SMTP id 6a1803df08f44-6d8f94518c9so338878536d6.1 for ; Tue, 07 Jan 2025 12:40:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736282405; x=1736887205; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=oXSaxIGrBHbOX/JDeWthayCloueSD2Pd/sShB7OcJNc=; b=lwoueRB7urb98N1rWzEvs1qr2HUJIjwmRPQlwIr9lnWujHPXtJA05gBnpWzgofCtIM 0CB3Xn9F9Q6giiUmPMA4mB1gZ5dq/9BWPXxvp8luZfpjYCL7e1BeUnrq4VsHdd3v9Bjh hC527VhzVJl9qKTd4tSkwii34ZVQJ4rUUSKcgs5czzrnowBauGBI0WAFFLzJZR+nOPO4 LAmhM6QYC+TbeYv7xnqVRKQOnftlIKm/gl0sxRrJF6Khz2RsNHGxAtRQ5tJnSMeJiFnI LIA07fgT6HhN2AL0WCKkHvj2cmBCH1UysSZGK5DkxkTyragoMfi4DQHiZR+iKRL1lClO bWOQ== X-Forwarded-Encrypted: i=1; AJvYcCXPDiwk2NgxtxMe9CeuFwcLtnB75e4Q/ykzlmKOAqURhZQNen6bfP8zOFwn7Pwp4x7Ml96o/BD4rxVLuUo=@vger.kernel.org X-Gm-Message-State: AOJu0YyA0JPe/27X2jdS0nkO8UhBxOcZUYWHOxlB7PRoXDkdzsv+ek6H 2ZAVcZRRJdAJIrrX+GQoTWiTImi2BqilAn5Bt8EZz3Nq1N9v4W+iCVbCOH1fQijEBgFPkQd6HSy rq7BH59Ddq7Zg/eLd4xobbamB4nGWzLaeESWUlh/Atbd6Jyhfa/27zpO5jraKoQ== X-Gm-Gg: ASbGncsrHXCYAt89XbeRM5EgCsyE4xf+jZ33DmN5LYrzDLCTyRdY6U4PACI9xv7fFDi A5c7/gPrAD5VaB5TkKi9VFzZx6/8G+dapHaY5BUgZP+qrRukeizaeD+n2nYYQbQeg6ABKeEZxvH LM79o5w258hcI3hoWejaYgG2+Pro5A/YhM+WD+1FYHZHYfxkmw6IUSivAeixLuiq1Te3BSx8bsI ZglG3vH+sA2oADSG3O7RIiZFyIEvKBhIgZbHircGYBFoSdw+vDpB9kIilcv3kBLYdG9n1ZriJoA Ed4Vp18qvoO5F+aM41HPTyHjv5jvhU2A X-Received: by 2002:a05:6214:c8c:b0:6d8:a486:e87e with SMTP id 6a1803df08f44-6df9b33ded1mr6995816d6.49.1736282405501; Tue, 07 Jan 2025 12:40:05 -0800 (PST) X-Google-Smtp-Source: AGHT+IHdrE6BHRlIB1SxuFQxwDqebIsWVKLARnXTWgDNEswCASHOe56LNxGGA+8+cFSe2wf+B55Zxg== X-Received: by 2002:a05:6214:c8c:b0:6d8:a486:e87e with SMTP id 6a1803df08f44-6df9b33ded1mr6995406d6.49.1736282405119; Tue, 07 Jan 2025 12:40:05 -0800 (PST) Received: from x1n.redhat.com (pool-99-254-114-190.cpe.net.cable.rogers.com. [99.254.114.190]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6dd181373f6sm184478306d6.62.2025.01.07.12.40.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Jan 2025 12:40:04 -0800 (PST) From: Peter Xu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Breno Leitao , Rik van Riel , Muchun Song , Naoya Horiguchi , Roman Gushchin , Ackerley Tng , Andrew Morton , peterx@redhat.com, Oscar Salvador Subject: [PATCH v2 0/7] mm/hugetlb: Refactor hugetlb allocation resv accounting Date: Tue, 7 Jan 2025 15:39:55 -0500 Message-ID: <20250107204002.2683356-1-peterx@redhat.com> X-Mailer: git-send-email 2.47.0 Content-Type: text/plain; charset="utf-8" Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit [based on akpm/mm-unstable, latest ca95745c20ad, of Jan 7th 2025] v2: - Rebase to latest mm-unstable - Added R-b and T-b for Ackerley on patch 1 (Ackerley: I was conservative on the tags here to only attach them in patch 1, even though it seems you mentioned you agree/tested with the whole series. Please feel free to provide your tag again on the cover letter if you want, thanks) This is a follow up on Ackerley's series here as replacement: https://lore.kernel.org/r/cover.1728684491.git.ackerleytng@google.com The goal of this series is to cleanup hugetlb resv accounting, especially during folio allocation, to decouple a few things: - Hugetlb folios v.s. Hugetlbfs: IOW, the hope is in the future hugetlb folios can be allocated completely without hugetlbfs. - Decouple VMA v.s. hugetlb folio allocations: allocating a hugetlb folio should not always require a hugetlbfs VMA. For example, either it got allocated from the inode level (see hugetlbfs_fallocate() where it used a pesudo VMA for allocation), or it can be allocated by other kernel subsystems. It paves way for other users to allocate hugetlb folios out of either system reservations, or subpools (instead of hugetlbfs, as a file system). For longer term, this prepares hugetlb as a separate concept versus hugetlbfs, so that hugetlb folios can be allocated by not only hugetlbfs and other things. Tests I've done: - I had a reproducer in patch 1 for the bug I found, this will start to work after patch 1 or the whole set applied. - Hugetlb regression tests (on x86_64 2MBs), includes: - All vmtests on hugetlbfs - libhugetlbfs test suite (which may fail some tests, but no new failures will be introduced by this series, so all such failures happen before this series so shouldn't be relevant). Comments welcomed, thanks. Peter Xu (7): mm/hugetlb: Fix avoid_reserve to allow taking folio from subpool mm/hugetlb: Stop using avoid_reserve flag in fork() mm/hugetlb: Rename avoid_reserve to cow_from_owner mm/hugetlb: Clean up map/global resv accounting when allocate mm/hugetlb: Simplify vma_has_reserves() mm/hugetlb: Drop vma_has_reserves() mm/hugetlb: Unify restore reserve accounting for new allocations fs/hugetlbfs/inode.c | 2 +- include/linux/hugetlb.h | 4 +- mm/hugetlb.c | 237 ++++++++++++++++++---------------------- 3 files changed, 107 insertions(+), 136 deletions(-) -- 2.47.0