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.129.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 E035159B71 for ; Fri, 3 Jan 2025 16:37:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735922278; cv=none; b=CkEbOj01hVXsAtE1ZXivsDwK1cD25aGlhjeQyNfvyzy2N4SL5zbkhKDoa0zc8UhgfUp8HIxgDjRtrVk5Qk547g1hcE1BTPBu/S2JuRM4rfHoLKaSuhI+XAWE2NqkNciEYqaAijE07stu9ZM42DrZKJlwwz2N+Cf8lY0Ixr8k5ic= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1735922278; c=relaxed/simple; bh=T2IB+2ba/QlkSESedF9rqUn+XaLmDp3EcoOOZs9JrzQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pF1Mp1xlK85FIdJjkdQAZTE5hDkrmHwXNnzbMYA6T2kDIqNDCSTmznth8PCZuY+GLP6R2L4WXK8T0j9goRsT6EgkiSVpot2cKqUNCFQhc7SKgGarTDOpgqp90NMdUQGVEuJAtjBsbUkAI20SyTcMGbQY9lcuAeEyUeAQcNafx28= 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=CwIn1P0I; arc=none smtp.client-ip=170.10.129.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="CwIn1P0I" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1735922275; 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=+CIOk0SKDOqby+Jn+3I/Ho2LKRgj6h18fSE1SsAzIhI=; b=CwIn1P0I6xFUiV7LG28AUfkhPotAUIRU2x9Jlo/V453jD2Ox+0Q2+1r0y0427av+PNKAJv gaD4peM1RcoO2AeqodSX0a862jX7/Ebnqe7RM5MPHAzPiG8A8v1saX2ULqSsTPZ5a7oaQE a0v/ADtPLTowAdbgGaSZLZ5s8EaHhso= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-75-BnXib48KN4yBuhZSLljo2A-1; Fri, 03 Jan 2025 11:37:54 -0500 X-MC-Unique: BnXib48KN4yBuhZSLljo2A-1 X-Mimecast-MFC-AGG-ID: BnXib48KN4yBuhZSLljo2A Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-7b6eeef7cb8so991721885a.2 for ; Fri, 03 Jan 2025 08:37:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735922274; x=1736527074; 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=+CIOk0SKDOqby+Jn+3I/Ho2LKRgj6h18fSE1SsAzIhI=; b=Jl7x0WT+wBqTmXbykSxmrGIr6NOb4UeiW3EXAZQeR3aG2A7kR6IQzIGNkHAAcCpuBp PZkFsvT27akRZDEEDJyoY6sJgOhflTlqjjyY85PVVT/Sb+mR0FRtmC8s6OYgZy3R5XYM Gwp6HT8QJ5nr0/tcl9U7+0PaxNVHnwgeGFaPDijn4eg+evA1PaQ9z0LMmhjXLFbnVRFk t7C/PmJefJ3BUhjxOqiyzZVBmy9fLry+/XRLtfFOTS3xsW2hUZc6j0O7JCDCw0RuhvGb y5IAeTjIF+mu6oJRS5FFvVKbDrs5DNzdXM1mP+F/xc4HP7AE8WnrCZwmF9fT1HB53ifb XyIg== X-Gm-Message-State: AOJu0YydGcVQkdo7HbViXwZglXbWp+HCeyt5eqptOdqgxSnGMBXKObHr zWt2MsqAl7gx7TX+V45QBBQkleSwuxfQEz4nBBqwVCwTvIXu753I9Xo+q8u+XvuD+TX52K3oWx5 NtnyX4iBkDgAG1hr7rrlvEzTH42n45802OOnpdBls43rSB6PiWUIvzDk4bE8d6A== X-Gm-Gg: ASbGncv8EHg3xDlV5do2C5NDASXXddSQ8VkM/atc5rKFav4yBl7aMrtRWD35DoSTjbk qrkHSaPzxrHSebLXcmj8ooYW4d7OptHY1LCR1rExqucWLIbUNm8dW6TxQWcHADSUm8CUiiHqMw2 yRQTSBkX2zEZN5kj3KGSEs2Mdtxx838GmNHY+CKWOCERUnCANh00V6ByD5J5j5HhI4JDQi6qiM1 EzATCQNf4tt2p437oMwvuGxPrmgWpaGrHZOPphObFBfiNqLY5iTgjoBGNkLpHgSwBFbKDanH+ty CrhXQD2m8QOYxeDzUw== X-Received: by 2002:ac8:7f8e:0:b0:467:64ef:9da6 with SMTP id d75a77b69052e-46a4a8add95mr874932711cf.10.1735922273646; Fri, 03 Jan 2025 08:37:53 -0800 (PST) X-Google-Smtp-Source: AGHT+IHA5y2FvIGqXlk9gDK5qZ6WKEF3iu5/KrxHAWCeQRFH/n/5v7rH2QUgrJyE4xgXb0FKfk3VSQ== X-Received: by 2002:ac8:7f8e:0:b0:467:64ef:9da6 with SMTP id d75a77b69052e-46a4a8add95mr874932361cf.10.1735922273363; Fri, 03 Jan 2025 08:37:53 -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 d75a77b69052e-46a3e6a60bfsm146416861cf.47.2025.01.03.08.37.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jan 2025 08:37:52 -0800 (PST) Date: Fri, 3 Jan 2025 11:37:49 -0500 From: Peter Xu To: Ackerley Tng Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, riel@surriel.com, leitao@debian.org, akpm@linux-foundation.org, muchun.song@linux.dev, osalvador@suse.de, roman.gushchin@linux.dev, nao.horiguchi@gmail.com Subject: Re: [PATCH 4/7] mm/hugetlb: Clean up map/global resv accounting when allocate Message-ID: References: <20241201212240.533824-5-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: On Sat, Dec 28, 2024 at 12:06:34AM +0000, Ackerley Tng wrote: > > > > - /* If this allocation is not consuming a reservation, charge it now. > > + /* > > + * If this allocation is not consuming a per-vma reservation, > > + * charge the hugetlb cgroup now. > > */ > > - deferred_reserve = map_chg || cow_from_owner; > > - if (deferred_reserve) { > > + if (map_chg) { > > ret = hugetlb_cgroup_charge_cgroup_rsvd( > > idx, pages_per_huge_page(h), &h_cg); > > Should hugetlb_cgroup_charge_cgroup_rsvd() be called when map_chg == MAP_CHG_ENFORCED? This looks like a pretty niche use case, though I would say yes. I don't think I take a lot of consideration here when drafting the patch, as the change here should have kept the old behavior: map_chg grows into the tristate so that we can drop deferred_reserve, OTOH nothing should change from such behavior of cgroup charging. When it happens, it means the owner process CoWed a private hugetlb folio which will enforce bypassing the vma reservation. Here bypassing the vma check makes sense to me, because the new to-be-cowed folio X will replace another folio Y, which should have consumed the private vma resv at this specific index. So there's no way the to-be-cowed folio X can have anything to do with the vma reservation.. Besides the vma reservation, I don't see why this folio allocation needs to be any more special. IOW, it should still go through all rest checks and fail the process properly if the check fails, that should include any form of cgroups (either hugetlb or memcg), IMHO. Do you have any specific thought on this path? Thanks, -- Peter Xu