Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp428119ybt; Wed, 24 Jun 2020 02:48:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyKdNg4UEVD7YDJNjAi6KAastAm9uP8wFIv2tn7BWZsMknSN/UKo42ZNPFuK45ZE2tZ7fJQ X-Received: by 2002:a17:906:1d1b:: with SMTP id n27mr15718879ejh.272.1592992114584; Wed, 24 Jun 2020 02:48:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592992114; cv=none; d=google.com; s=arc-20160816; b=vIN4EGrTae97MeivbtwGYn4AaX17u2MSCANnp9PKnDHLG1o5u6YWADJwoKnNW+mdVT 2Z+9jQGBE2xNsxnnBrzKOMS1cMczRxcH4RJgg5sxoFoaRvjkLSvQ3j6hS51hJVN08Fgf XLanltaU0bOo1vMUlDPvBcJvdcMm28gXNj/P4tp6ti6nLqi9eE6WXOPO84Aa3MnPtALc WEbCISsDJ8hH+nBiG4JlTVkxisNO057fkmyvfUx0HLWvHkbm5TkBCGP/7xRIqOrQrfoZ /kgJBKPHTreJTI3CjpLCOFirUcRrvxmd6Fi3p5XtnqlM5dEYqTx+fP9VNPYPoJe6RPoy 4DDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=sM2oWwoDBtn4yXPlxoFaATCDPS2GuuFuvEzIEsjdUnI=; b=QAXxIO4EW4kVj3byrzKlGXvezWEWwhkvW/JCLfGedD919TqcJpJu3NqGIkz7E1i6tP gcEZ8Hv/erpTc42EtK2/3rIBZq1crSao83E+IeIpqIreDDfVCpuWhgPUNu/SxcCzYEHr 8O5MpHVgnx9GUvk1wG6kU8o2q9InugUNd9o36IfHs3US0yevd3mfIpO+tcQ2QkXbHiO/ /j4RCWhITa21NBmAd1Tme0kEJMCX8gPXEJh62Jv/wFNz35HgXAFU1v8Bms3riCs3WxPa blsWWjD0FpKrYiXQ6HSL6Pe543PTa6pZNCeHsUGwriPkrZTGoJxyiPel91h7n0wm0q7s f9Ew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r24si8211287edp.282.2020.06.24.02.47.56; Wed, 24 Jun 2020 02:48:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389330AbgFXJrf (ORCPT + 99 others); Wed, 24 Jun 2020 05:47:35 -0400 Received: from mail-ed1-f65.google.com ([209.85.208.65]:38247 "EHLO mail-ed1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388031AbgFXJrf (ORCPT ); Wed, 24 Jun 2020 05:47:35 -0400 Received: by mail-ed1-f65.google.com with SMTP id cy7so1014619edb.5 for ; Wed, 24 Jun 2020 02:47:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=sM2oWwoDBtn4yXPlxoFaATCDPS2GuuFuvEzIEsjdUnI=; b=g+qX/+pzVwXBT6osZkheGdLTlO+26DeGeUJZhSmw5qDrFuls12iNIMlzcykmPIl7O0 FqfSciMNwgY8gDSXwSrEOWirb5STXxZDkWWBU5R2HhWyngB4RpmsclZ7Qb8VBhMmeCZZ S1aQNMBx+VcnzC/5peIALmXhWAFLPev4V7q+ZNu0ygPGnxEB9Yp0Ny2ZzJsWZoKM9tqY mXihYkREta58lHDcgbc3+051bdCyxWK8YVl4IgEfpHMgG1KOi6xbCO6nwWSVu8yx2MoC VYT1EBh3XyfircKJrVKH0c/ZlEd1rMIS7jlL9axf9t2ystwbdj8LWq7rxTssCAfN5X2p xS4Q== X-Gm-Message-State: AOAM53208Gd4EC5IFDqANv3LQU38e9uY7WRa7GYww+k0HAw+PjuL5msV lAyjFo5R3/76neRtJ7jFWP/c8cqX X-Received: by 2002:aa7:c756:: with SMTP id c22mr26316545eds.239.1592992052986; Wed, 24 Jun 2020 02:47:32 -0700 (PDT) Received: from localhost (ip-37-188-168-3.eurotel.cz. [37.188.168.3]) by smtp.gmail.com with ESMTPSA id fi29sm3416940ejb.83.2020.06.24.02.45.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 02:46:01 -0700 (PDT) Date: Wed, 24 Jun 2020 11:45:52 +0200 From: Michal Hocko To: Andrew Morton , Feng Tang Cc: Johannes Weiner , Matthew Wilcox , Mel Gorman , Kees Cook , Luis Chamberlain , Iurii Zaikin , andi.kleen@intel.com, tim.c.chen@intel.com, dave.hansen@intel.com, ying.huang@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 0/3] make vm_committed_as_batch aware of vm overcommit policy Message-ID: <20200624094552.GI1320@dhcp22.suse.cz> References: <1592725000-73486-1-git-send-email-feng.tang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1592725000-73486-1-git-send-email-feng.tang@intel.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andrew, I do not see these patches in mmotm tree. Is there anything blocking them? There used to be v3 in the tree (http://lkml.kernel.org/r/1589611660-89854-4-git-send-email-feng.tang@intel.com) but that one got dropped due some failures. I haven't seen any failures for this one. On Sun 21-06-20 15:36:37, Feng Tang wrote: > When checking a performance change for will-it-scale scalability > mmap test [1], we found very high lock contention for spinlock of > percpu counter 'vm_committed_as': > > 94.14% 0.35% [kernel.kallsyms] [k] _raw_spin_lock_irqsave > 48.21% _raw_spin_lock_irqsave;percpu_counter_add_batch;__vm_enough_memory;mmap_region;do_mmap; > 45.91% _raw_spin_lock_irqsave;percpu_counter_add_batch;__do_munmap; > > Actually this heavy lock contention is not always necessary. The > 'vm_committed_as' needs to be very precise when the strict > OVERCOMMIT_NEVER policy is set, which requires a rather small batch > number for the percpu counter. > > So keep 'batch' number unchanged for strict OVERCOMMIT_NEVER policy, > and enlarge it for not-so-strict OVERCOMMIT_ALWAYS and OVERCOMMIT_GUESS > policies. > > Benchmark with the same testcase in [1] shows 53% improvement on a > 8C/16T desktop, and 2097%(20X) on a 4S/72C/144T server. And for that > case, whether it shows improvements depends on if the test mmap size > is bigger than the batch number computed. > > We tested 10+ platforms in 0day (server, desktop and laptop). If we > lift it to 64X, 80%+ platforms show improvements, and for 16X lift, > 1/3 of the platforms will show improvements. > > And generally it should help the mmap/unmap usage,as Michal Hocko > mentioned: > > : I believe that there are non-synthetic worklaods which would benefit > : from a larger batch. E.g. large in memory databases which do large > : mmaps during startups from multiple threads. > > Note: There are some style complain from checkpatch for patch 3, > as sysctl handler declaration follows the similar format of sibling > functions > > [1] https://lore.kernel.org/lkml/20200305062138.GI5972@shao2-debian/ > > patch1: a cleanup for /proc/meminfo > patch2: a preparation patch which also improve the accuracy of > vm_memory_committed > patch3: main change > > This is against today's linux-mm git tree on github. > > Please help to review, thanks! > > - Feng > > ---------------------------------------------------------------- > Changelog: > > v5: > * rebase after 5.8-rc1 > * remove the 3/4 patch in v4 which is merged in v5.7 > * add code comments for vm_memory_committed() > > v4: > * Remove the VM_WARN_ONCE check for vm_committed_as underflow, > thanks to Qian Cai for finding and testing the warning > > v3: > * refine commit log and cleanup code, according to comments > from Michal Hocko and Matthew Wilcox > * change the lift from 16X and 64X after test > > v2: > * add the sysctl handler to cover runtime overcommit policy > change, as suggested by Andres Morton > * address the accuracy concern of vm_memory_committed() > from Andi Kleen > > Feng Tang (3): > proc/meminfo: avoid open coded reading of vm_committed_as > mm/util.c: make vm_memory_committed() more accurate > mm: adjust vm_committed_as_batch according to vm overcommit policy > > fs/proc/meminfo.c | 2 +- > include/linux/mm.h | 2 ++ > include/linux/mman.h | 4 ++++ > kernel/sysctl.c | 2 +- > mm/mm_init.c | 18 ++++++++++++++---- > mm/util.c | 19 ++++++++++++++++++- > 6 files changed, 40 insertions(+), 7 deletions(-) > > -- > 2.7.4 > > -- Michal Hocko SUSE Labs