From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AA89B7082A for ; Mon, 6 Jan 2025 14:48:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736174896; cv=none; b=CHa4L01yit12gye2ZBTDZVV8MqYdAotI5SbiC0SS2PWRmreNG38dJka1Nl0Yvi0PzFvno1PmxH/CCyrZWeLWyAU7QPdXZfta7gIDL0t15nuFCAi2tMCNxbqXzb/hnTgb7zdogz6b8n6LN6JxVVFkmOsuzY2T+OqoISyxuONdkZY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736174896; c=relaxed/simple; bh=uMjdX3OYkP1Xuox3NHvPyCFfTdlz+8ytRQRRUSVHb/g=; h=Date:In-Reply-To:Mime-Version:Message-ID:Subject:From:To:Cc: Content-Type; b=KPwLZ4AQ0RdeaVKgfMJrJCvZeovdgeDupHxsdHQC7c/ZH2bJxPZOTC6C3sWk1SaSWK3wt1AoI2E9VGGg1p22XlYztrBAH6OwuTZOEfnNVWHpbg5njYESdH8gSvyuOWMH7k5nzFXfavpcQTP3GzeI6w0BsESSCZxOLOW8QW3A6k4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--ackerleytng.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=wq7DhrSt; arc=none smtp.client-ip=209.85.216.73 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--ackerleytng.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="wq7DhrSt" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-2ee3206466aso19834930a91.1 for ; Mon, 06 Jan 2025 06:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736174894; x=1736779694; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:in-reply-to:date:from:to :cc:subject:date:message-id:reply-to; bh=Ke8uVppptY2MOt7pG36E0z4Uz4tqJsCG9hU95Nn9QHU=; b=wq7DhrStxwOgaih+lyMpyJZ3IYCa5TP+CCP1CoiNBch0q0iWCs5lIazGnN3OALmVrL V+CAFIwp6go+CnF+cye6aTl2UZnaRsCimHkJSsoQk+N/8Np9gpzd3XKh0RG3dXvimIAt lheUvxAKr+XAw2MUxQuewk5eXaeKGtyH/BksSK2lOQ+OwxKAPKChgTvs1FbPunHjRGcg zrVF+zzZrVcaHH1ySfm0TVM1aZSgNqxVCnMvVWofOKbuVADYaBIgMWejrDCN7St/0+g0 PzVRWNPJgpUqMJJTxtcXNAoQP9d7Q0oYFEduILGrGHPGp1YCQN/UPf0dEYvMqQdaRAaF TeGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736174894; x=1736779694; 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=Ke8uVppptY2MOt7pG36E0z4Uz4tqJsCG9hU95Nn9QHU=; b=NyNkzVHY7kSby5hV7fmwt48onhOujzvryDBZHskYzDemH+5GPdxX6LFM5KY/ngGgzV X099vGrTuFbmV4dfnn9U1HTa/k8ADe5qjdHottEP9qrQI0JOEnSGTIu9Oa4TCbOH0+cu 9478p5HZTW+D64tQ3Ds0PCojusPyS5tlsgQ2/zI4gbAn0AwavSrSGYD85DTeT26sKgJM Zl3wcRzW/IFBE7Ijn7+NvphF+kTBdmWddNuU84uYn3HisYFeBqql5a1R570jL1bkAhGs +HM0R9xZ7jvSPDMgUjNE5f1T26P910XO1BF51fJ9dVhYrP6EMJch1gKvekL+29Qxezic gtAQ== X-Gm-Message-State: AOJu0Yxncr6KIB1/Zk91+pg0FCtXdEVh2GQwZhvfnIXQXohXNxuoSGHh nubGonjd2BWkIYVFjcko3GTi6XYki3xhzWJnTn0otRs5oF31sxcgxJCed+hi3Jo8qDy1cQRcTYH CxyBFlLKzjy8CrVg2UEmHUw== X-Google-Smtp-Source: AGHT+IE3URkXgEjN0yB/+uLqvfcZ3vLVzWvGm8LFGBGtPRgPCRwZ0+NIGL9DJ4h1v0Ui1iS87YlI+rbYcsTUYPBuMQ== X-Received: from pjbsn7.prod.google.com ([2002:a17:90b:2e87:b0:2e2:9021:cf53]) (user=ackerleytng job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:4d08:b0:2ee:823e:39c4 with SMTP id 98e67ed59e1d1-2f45363734emr96196196a91.7.1736174893918; Mon, 06 Jan 2025 06:48:13 -0800 (PST) Date: Mon, 06 Jan 2025 14:48:12 +0000 In-Reply-To: (message from Peter Xu on Fri, 3 Jan 2025 11:37:49 -0500) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Message-ID: Subject: Re: [PATCH 4/7] mm/hugetlb: Clean up map/global resv accounting when allocate From: Ackerley Tng To: Peter Xu 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 Content-Type: text/plain; charset="UTF-8" Peter Xu writes: > 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? I re-read the code, and I hope this understanding is right: When a user sets "rsvd.max_usage_in_bytes" to X, the user is saying that within this cgroup, the maximum memory that can be reserved in the vma reservation is X. Hence even when this CoW is performed, this should count towards the cgroup's "rsvd.max_usage_in_bytes" and so yes, it should be charged. I think I misunderstood the context on cgroup charging earlier and hence I thought it shouldn't be charged, but I agree with you after re-reading. > > Thanks,