From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A432EC433DF for ; Fri, 10 Jul 2020 21:42:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7E5272077D for ; Fri, 10 Jul 2020 21:42:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594417346; bh=Jvzm1Kng6lhm18W8nLR/n2xhwiIFBQHMhWdB8A3TvwI=; h=Date:From:To:Subject:Reply-To:List-ID:From; b=2u3W60z8aO+jR4joqLfRe1JCjqjWK1X7M5sxSCkJ3eGlfA4Tr7ppHrrFuTGtBm5Nj Jz4YAu/aW59lv4mcN4iejOaN47VA3FoLOs17u3bdFFBdk0EkbQMjfjBvxHhk8x8AUu b4IR156OGFzhNJGKtrF2kJE9XId2iRe+lQ2f6NjM= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726342AbgGJVm0 (ORCPT ); Fri, 10 Jul 2020 17:42:26 -0400 Received: from mail.kernel.org ([198.145.29.99]:45200 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726275AbgGJVm0 (ORCPT ); Fri, 10 Jul 2020 17:42:26 -0400 Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EEC742075D; Fri, 10 Jul 2020 21:42:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1594417345; bh=Jvzm1Kng6lhm18W8nLR/n2xhwiIFBQHMhWdB8A3TvwI=; h=Date:From:To:Subject:From; b=zGtnrljYCQ/DBshvzjlavuZ/hZ8dTTGSrsBfoXk7QPPIQON0xd7laILcVU6ag/Z6Y DPKHwq3mdOSka6vkvRnnQc5/3oBe90dhdEiw6U1nVNHVpUfX9KWyDerO+/NPr2no7x TVT91gZVaAyog8yTp1/2NMvDBUssGKvpaOerZR1Y= Date: Fri, 10 Jul 2020 14:42:24 -0700 From: akpm@linux-foundation.org To: andi.kleen@intel.com, cai@lca.pw, cl@linux.com, dave.hansen@intel.com, dennis@kernel.org, feng.tang@intel.com, haiyangz@microsoft.com, hannes@cmpxchg.org, keescook@chromium.org, kys@microsoft.com, mgorman@suse.de, mhocko@suse.com, mm-commits@vger.kernel.org, rong.a.chen@intel.com, tim.c.chen@intel.com, tj@kernel.org, willy@infradead.org, ying.huang@intel.com Subject: + mm-utilc-make-vm_memory_committed-more-accurate.patch added to -mm tree Message-ID: <20200710214224.Co9G8fqk_%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 Sender: mm-commits-owner@vger.kernel.org Precedence: bulk Reply-To: linux-kernel@vger.kernel.org List-ID: X-Mailing-List: mm-commits@vger.kernel.org The patch titled Subject: mm/util.c: make vm_memory_committed() more accurate has been added to the -mm tree. Its filename is mm-utilc-make-vm_memory_committed-more-accurate.patch This patch should soon appear at http://ozlabs.org/~akpm/mmots/broken-out/mm-utilc-make-vm_memory_committed-more-accurate.patch and later at http://ozlabs.org/~akpm/mmotm/broken-out/mm-utilc-make-vm_memory_committed-more-accurate.patch Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next and is updated there every 3-4 working days ------------------------------------------------------ From: Feng Tang Subject: mm/util.c: make vm_memory_committed() more accurate percpu_counter_sum_positive() will provide more accurate info. As with percpu_counter_read_positive(), in worst case the deviation could be 'batch * nr_cpus', which is totalram_pages/256 for now, and will be more when the batch gets enlarged. Its time cost is about 800 nanoseconds on a 2C/4T platform and 2~3 microseconds on a 2S/36C/72T Skylake server in normal case, and in worst case where vm_committed_as's spinlock is under severe contention, it costs 30~40 microseconds for the 2S/36C/72T Skylake sever, which should be fine for its only two users: /proc/meminfo and HyperV balloon driver's status trace per second. Link: http://lkml.kernel.org/r/1592725000-73486-3-git-send-email-feng.tang@intel.com Link: http://lkml.kernel.org/r/1594389708-60781-3-git-send-email-feng.tang@intel.com Signed-off-by: Feng Tang Acked-by: Michal Hocko # for /proc/meminfo Cc: "K. Y. Srinivasan" Cc: Haiyang Zhang Cc: Matthew Wilcox (Oracle) Cc: Johannes Weiner Cc: Mel Gorman Cc: Qian Cai Cc: Andi Kleen Cc: Tim Chen Cc: Dave Hansen Cc: Huang Ying Cc: Christoph Lameter Cc: Dennis Zhou Cc: Kees Cook Cc: kernel test robot Cc: Tejun Heo Signed-off-by: Andrew Morton --- mm/util.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) --- a/mm/util.c~mm-utilc-make-vm_memory_committed-more-accurate +++ a/mm/util.c @@ -787,10 +787,15 @@ struct percpu_counter vm_committed_as __ * balancing memory across competing virtual machines that are hosted. * Several metrics drive this policy engine including the guest reported * memory commitment. + * + * The time cost of this is very low for small platforms, and for big + * platform like a 2S/36C/72T Skylake server, in worst case where + * vm_committed_as's spinlock is under severe contention, the time cost + * could be about 30~40 microseconds. */ unsigned long vm_memory_committed(void) { - return percpu_counter_read_positive(&vm_committed_as); + return percpu_counter_sum_positive(&vm_committed_as); } EXPORT_SYMBOL_GPL(vm_memory_committed); _ Patches currently in -mm which might be from feng.tang@intel.com are proc-meminfo-avoid-open-coded-reading-of-vm_committed_as.patch mm-utilc-make-vm_memory_committed-more-accurate.patch percpu_counter-add-percpu_counter_sync.patch mm-adjust-vm_committed_as_batch-according-to-vm-overcommit-policy.patch