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 36F941531E3 for ; Mon, 13 Jan 2025 16:19:36 +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=1736785178; cv=none; b=kp2JZHyG2/OyvLr+/mPWMxYDn/McVrSdsfrNH75cqkHvpg6Fts/qyJNqmAksv8A4pZLo5AZqAJM1MuAKn/WJN3ykBtWh6mIQx2AdABg6xB1j5RRY7LKjOTON2UI5T6ZmaNVQ7xJ9xbT/JwRE4DfGtOppP8i+0wrR4irIp9w7VJg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736785178; c=relaxed/simple; bh=ROsjMBIr9/fn2IXueVxlYXR51EQxhv7T99jkcX5dpTI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=hVF4cjWPMFUjc37oWsqpLcDPp4HeXNNXVX06CopJyWRiuYN763JPpuMNEMib650zVPdyJM4OVwzfbLJRuQ2HeZmKt2wTBZUWYXlGZuagTA34kj12fHNMlnZfQCDj1X0+uMZEw+IEnbSj+kzsk3q4lsh838jILopdockXXjxYKA4= 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=ipAjtkxC; 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="ipAjtkxC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1736785176; 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: in-reply-to:in-reply-to:references:references; bh=IDkV1rDSOYmAm8RJGxE2x5aaSSKCEneZP3d7jqhBPY8=; b=ipAjtkxCC0Y03biZgm0cnSvdltG67cZwoSOvGWzpZ8H5UeE5ocxJ15jdzTUHz3B6q9rq8N g3o2a2eYgQ51ZCWAcgOc9wZXlITSak5QxvqEJH8Q1ftBPKqVHn0cej7NtnGAKZlyqx89oY 4snDK7ZDVY1O82iy1bwV5eELnufB3g4= Received: from mail-pl1-f199.google.com (mail-pl1-f199.google.com [209.85.214.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-338-cUgujeWzMUy8bNLlivpE2A-1; Mon, 13 Jan 2025 11:19:34 -0500 X-MC-Unique: cUgujeWzMUy8bNLlivpE2A-1 X-Mimecast-MFC-AGG-ID: cUgujeWzMUy8bNLlivpE2A Received: by mail-pl1-f199.google.com with SMTP id d9443c01a7336-2166e907b5eso82973635ad.3 for ; Mon, 13 Jan 2025 08:19:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736785174; x=1737389974; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=IDkV1rDSOYmAm8RJGxE2x5aaSSKCEneZP3d7jqhBPY8=; b=rxWkD3PvGi6r9FKcvbIr/cQlrsHRfpP2evg0+SyTdqf3t4AddiE2k+3frFsJVzcYfv +FKlOMlmZZcccBmOPySEV/gUFu4sFfxRVuCnV5HsziYCF7NaRZXr4gC+CI5J9QRRbQVJ GJp3wku6B6iJb+ijaWb+trSnMfm3hdHh7duPRLneMVHwqS5Pr/M2laW7Xw4GUs2pLjWB Fld/4+4eqH33N1EwUc0AuXG79DQ17Y0ttK//SfcnzHAwCVvCTPDB/RsKtwOiewWdFEbS sjeaMv+PmwY2YeHE95FVb7Z8Emph2hkA5/IGoyqPzDMEKz3O0x2sdDrUoBwdb0JYsE6D mEkA== X-Forwarded-Encrypted: i=1; AJvYcCXoNe4CkHgFjvn9tZf+DjRIEspyG3/kdgYLGaYsEvu5khzfo+APwxiMIQ25QtZskTT0poHCzMtazGjsB6E=@vger.kernel.org X-Gm-Message-State: AOJu0YxtfvK8+1JnWMs0vlnLTZEjTEhsZ4B3HjsFzty+pnstf6YA6UvI eeCBwdfQBGYI7GOrVLzqrEvHBw15dpR4BGz6X1OkZDkbTU9rrtsrpZxsvuQNuF/3amJZ04VeQRO OKmABH/rN/BRmqH/UxRTvPDiBXIk7GuKEkHWPmNVxwxdSdyLpGcbLJb96SSjMZw== X-Gm-Gg: ASbGncvsIpc05jHM6SpcbG3tVrvzXm5/T28wZ2uqHkMhY/BDcyg8LnmaN+g0JC9l6oc ifYKIsdmHIFBRrqIxYZ7SozKsdQDQ3BMzP2LTnujfsJLoOPJDzwfk+TfZeZlo4mPKc5Qw5nCbkR LbYqVTc7NXFZsYTX8Gn8xwC9S9KYNutFqzCovjOCCoTazJ6noPLoBgwbc4Kq8b5bK6g2E1V7h72 4trYQ09no984nBV4OK8JqLKN2k4EIJgL7BJU+mVUa+9R3vY0N6jQP5y+owOnRHNcIBd4MQ3vdDV Jv9zcfEbRnKS6c+oWw== X-Received: by 2002:a05:6a20:9c8d:b0:1e1:af70:a30b with SMTP id adf61e73a8af0-1e88d0bfa31mr41021657637.34.1736785173786; Mon, 13 Jan 2025 08:19:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IH7f7ZjP3Dus301GWs4eZ6h8/R/3+H6waRmZqFuSic1aNEpNhpwa0Db6ehH+Pt725zAU12rVQ== X-Received: by 2002:a05:6a20:9c8d:b0:1e1:af70:a30b with SMTP id adf61e73a8af0-1e88d0bfa31mr41021617637.34.1736785173470; Mon, 13 Jan 2025 08:19:33 -0800 (PST) Received: from x1n (pool-99-254-114-190.cpe.net.cable.rogers.com. [99.254.114.190]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72d4065c3b4sm6076135b3a.112.2025.01.13.08.19.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jan 2025 08:19:32 -0800 (PST) Date: Mon, 13 Jan 2025 11:19:27 -0500 From: Peter Xu To: Oscar Salvador Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Breno Leitao , Rik van Riel , Muchun Song , Naoya Horiguchi , Roman Gushchin , Ackerley Tng , Andrew Morton Subject: Re: [PATCH v2 3/7] mm/hugetlb: Rename avoid_reserve to cow_from_owner Message-ID: References: <20250107204002.2683356-1-peterx@redhat.com> <20250107204002.2683356-4-peterx@redhat.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Oscar, On Mon, Jan 13, 2025 at 12:20:34PM +0100, Oscar Salvador wrote: > On Tue, Jan 07, 2025 at 03:39:58PM -0500, Peter Xu wrote: > > The old name "avoid_reserve" can be too generic and can be used wrongly in > > the new call sites that want to allocate a hugetlb folio. > > > > It's confusing on two things: (1) whether one can opt-in to avoid global > > reservation, and (2) whether it should take more than one count. > > > > In reality, this flag is only used in an extremely hacky path, in an > > extremely hacky way in hugetlb CoW path only, and always use with 1 saying > > "skip global reservation". Rename the flag to avoid future abuse of this > > flag, making it a boolean so as to reflect its true representation that > > it's not a counter. To make it even harder to abuse, add a comment above > > the function to explain it. > > > > Signed-off-by: Peter Xu > > I agree that the current name is quite misleading, and this patch > improves the situation substantially. > The only thing I am missing here is that the comment you added could be > more explanatory as to why new call sites do not want to make use of the > flag. > > IIRC, not using so, will bypass all vma level reservations as you s/not using/using/? Only using the flag (setting to true) will bypass vma, but I could have misunderstood this line.. > mentioned, which means that the child can get killed if the parent > makes use of the page, as it is the parent the only one that made a > reservation. The paragraph I added on top of alloc_hugetlb_folio() is trying to suggest nobody should set this to true in any new paths. So far, the reservation path should have nothing relevant to stealing page on its own (if that is what you meant above..) - page stealing in hugetlb private is done separately within the unmap_ref_private() helper. Here the parent needs to bypass vma reservation because it must have consumed it with the folio installed in the pgtable (which is write-protected). That may or may not be relevant to page stealing, e.g. if global pool still has free page it doesn't need to affect child from using its hugetlb pages. However again I could have totally misunderstood your comment.. > > So maybe dropping a hint would be nice. > > Reviewed-by: Oscar Salvador Thanks for taking a look! -- Peter Xu