Received: by 2002:ab2:687:0:b0:1f4:6588:b3a7 with SMTP id s7csp212656lqe; Tue, 9 Apr 2024 22:22:46 -0700 (PDT) X-Forwarded-Encrypted: i=3; AJvYcCVz5k/ubNb32smcOZPClhSc6tu7XKbrBNMUn1KCor5i3QqD2zsWQUIcbXgoIiZ5gQG2bj02FRUrf9iqyQzJv4iKkmLSRYv01KvAyIrl+A== X-Google-Smtp-Source: AGHT+IF82RMeyOYljgE4gTqGRePDej6qqQlbNnaoQYaLviWHO1sIZIT31FZrtqmfttVh6POGBU9N X-Received: by 2002:a0d:cccd:0:b0:615:1a18:11d7 with SMTP id o196-20020a0dcccd000000b006151a1811d7mr1740197ywd.0.1712726566219; Tue, 09 Apr 2024 22:22:46 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1712726566; cv=pass; d=google.com; s=arc-20160816; b=jFuFOz7rGloCibrOdLDV9ETJBz252/AhI5zFqx3KcBZ79kWjUzSiztDUvcTafQfgoK I0cqcWgYg5N6snGrk9GkWTysnuVAnkgz7b3BQ927DW/uOc1wtmJ1Ohqd7dBqj/nYq7U6 LenwtvoGvdyyhItKpDvgsGb7iKQYTvgo/MScUxxw64g0OzZZFeLr9zsOXmUWGldN7EtR BST2iidm7g+upUHy7aGT3gCZyX/sb+0OE8177BvPvhiNtc/ZR6zdTjDpfIrIkAi5UkZL IqnaBRfbCmG5wz7Lv2MuymZoq2jciDMW6+YjIZK5k2epCH1+cNKJxPyDR3AnfF7iDYCu c09g== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:list-unsubscribe:list-subscribe:list-id:precedence :user-agent:content-transfer-encoding:references:in-reply-to:date:cc :to:from:subject:message-id:dkim-signature; bh=0lzs+qPY7BUZt3XXSWZ0lLk+fJmux2RYy+140ZGLMD4=; fh=9K3nyHkJwGlH52WDgrCB4Obw1jpSZaAWl6vbDTUBzvQ=; b=UxT3ZbUd6By57wESjjf0Xx+8RfQJnGUWAq2Y56U1I7pkxtNde3HOEDKY3vhwbOOUNo 5vpxFGwrmtazUfmq8DkRQJSzMbsSc+JIqJmg+IsfwtDKyfSzKb3c5xqqjfQmzFwp950m ysQ7WaKQDMKPMOyI96LrnnU5x951YnDSUIHI2fmuXgAoAGQWDy/leotkju0rFltY9AHL 0CmJLMfp9WhoqY/SrUQV7Y15YyrbnSerVH8gc3kdyh4MSVMZw+1g2uqARzXQtO4TyJHV GLlc5S06pYdbdMBobh4wdosKtalIg1C8UbDIjHu4bNXH17wnN+pHT7GV0MI8+Uz/RpkZ +IEg==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=JSBUiON5; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-137831-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-137831-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from sy.mirrors.kernel.org (sy.mirrors.kernel.org. [147.75.48.161]) by mx.google.com with ESMTPS id b186-20020a6334c3000000b005f3c8f1f441si10192630pga.640.2024.04.09.22.22.45 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 09 Apr 2024 22:22:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel+bounces-137831-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) client-ip=147.75.48.161; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=JSBUiON5; arc=pass (i=1 dkim=pass dkdomain=intel.com dmarc=pass fromdomain=linux.intel.com); spf=pass (google.com: domain of linux-kernel+bounces-137831-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.48.161 as permitted sender) smtp.mailfrom="linux-kernel+bounces-137831-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sy.mirrors.kernel.org (Postfix) with ESMTPS id 3CB46B22470 for ; Wed, 10 Apr 2024 02:17:24 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id ABA788C10; Wed, 10 Apr 2024 02:17:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="JSBUiON5" Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) (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 6B74120EB for ; Wed, 10 Apr 2024 02:17:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.17 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712715430; cv=none; b=pL7/GnvVnWHC0j422ADSrVM88zGXSMpHy64Fndtk1/U+jQAVoib8CTSBrHAZ/z0Eb5lZ24mfghg8v1O3rp7uX8phf64eMyRfio1//aJohAGBMk7LHJppNwXLPFvT/BQYLzXLZlLpG428vn5+lnLTiGSMwzOxhiyxZxu8PcOUhzQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712715430; c=relaxed/simple; bh=O6C6n9pybJTJLPJy1c8WzpgKVw+uUnnwKizzYQ7blj4=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=XBoGfB7QH6+x+G0evRgFs4kUhL1hVyuN8vsNfTmi46RK5GT1UVIqJYXUYEUFVnRrkMzRx0UrJO32hXm6Eh3pBzsSkAz97Ft72J5LPUjozcB9RGDQIpzcW6QQo8eJzQygt6CO+Hz7sfqYvHiHutORmOkv2XSSBDSQxGk0HPv0JNs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=none smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=JSBUiON5; arc=none smtp.client-ip=198.175.65.17 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=linux.intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1712715430; x=1744251430; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=O6C6n9pybJTJLPJy1c8WzpgKVw+uUnnwKizzYQ7blj4=; b=JSBUiON5P+HMBeBGx6j8oZByqAqn7X09CG+tkBbUQjNv2iJ32IQaJ3Lf bXBfSsbvGbwhZYZtyfgmpxZY3k+QtRJZAXksI3zzPyKbtJERN/yPw2woN FlrxZDhKZ2U0ks5488x50LpNfWTQMzmzKFknkeoJnic/Jvz6Rolm9fYQx bW/WA4PV+xMDyIPlFIdV1vgDb09N2IVC5gWeD0sa7/m1+hSHx5s6tGVUB hshL4jOMQtCPvPqPREuvEkocEPcMZWtd9HrMV/yeK3LazzdfIZcdD+KP0 oRrDnpKHRrQ8OJ6qdZMBkbxN6hAZ45Uaz/XV1Ar5U7dY9NpoD+ENox5Xy w==; X-CSE-ConnectionGUID: JNWCY562TVupDYaxbxsa4A== X-CSE-MsgGUID: TTkrDxjfQCqYYBjVDUN1KA== X-IronPort-AV: E=McAfee;i="6600,9927,11039"; a="8161293" X-IronPort-AV: E=Sophos;i="6.07,190,1708416000"; d="scan'208";a="8161293" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Apr 2024 19:17:10 -0700 X-CSE-ConnectionGUID: TXOFrYDjTyiFtmhcOf1iKQ== X-CSE-MsgGUID: PGZlSwBjSt+v7vtpIZ8YWA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.07,190,1708416000"; d="scan'208";a="24908586" Received: from amatsuba-mobl2.amr.corp.intel.com (HELO [10.209.3.203]) ([10.209.3.203]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Apr 2024 19:17:10 -0700 Message-ID: <19a3c2890b18ce230a9e147c0eeee27caf0c4137.camel@linux.intel.com> Subject: Re: [RFC] mm: get_mm_counter() get the total memory usage of the process From: Tim Chen To: Chen Taotao , akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org Date: Tue, 09 Apr 2024 19:17:08 -0700 In-Reply-To: <20240322151139.7417-1-chentt10@chinatelecom.cn> References: <20240322151139.7417-1-chentt10@chinatelecom.cn> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4 (3.44.4-2.fc36) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Fri, 2024-03-22 at 23:11 +0800, Chen Taotao wrote: > Currently, the get_mm_counter() function returns only the value of > the process memory counter percpu_counter ->count record, ignoring > the memory usage count maintained by each CPU in the > percpu_counter->counters array, which leads to an error in obtaining > the memory usage count of a process, especially when there are many > CPU cores. counts, especially when there are many CPU cores. >=20 > It is now possible to have get_mm_counter() get the memory count of a > process by adding the memory counts maintained by each cpu, thus getting > an accurate memory count of the process. >=20 > This patch is an unofficial version that simply fixes the above problem, > as I'm not sure if it makes sense to do so. Summing up the mm counts maintained in every cpu is expensive, especially if we are doing the read often. More so when there are a large number of cores on large servers or newer CPU with high core counts. For mm counters,the count in fbc->count is good enough we don't need to correct fbc->count with the the small counts update (< percpu_counter_batch) cached in per cpu counts. So do you have a mm count use case where you really need the precise count with get_mm_counter? I do not think we should make the change you suggested. Tim >=20 > Signed-off-by: Chen Taotao > --- > include/linux/mm.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >=20 > diff --git a/include/linux/mm.h b/include/linux/mm.h > index f5a97dec5..5cf6443aa 100644 > --- a/include/linux/mm.h > +++ b/include/linux/mm.h > @@ -2569,7 +2569,7 @@ static inline bool get_user_page_fast_only(unsigned= long addr, > */ > static inline unsigned long get_mm_counter(struct mm_struct *mm, int mem= ber) > { > - return percpu_counter_read_positive(&mm->rss_stat[member]); > + return percpu_counter_sum_positive(&mm->rss_stat[member]); > } > =20 > void mm_trace_rss_stat(struct mm_struct *mm, int member);