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=-0.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 53F38C433E1 for ; Mon, 18 May 2020 22:38:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0B03B20829 for ; Mon, 18 May 2020 22:38:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="okjC93SP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B03B20829 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6C4EE900003; Mon, 18 May 2020 18:38:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 64EEA900002; Mon, 18 May 2020 18:38:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 53CFF900003; Mon, 18 May 2020 18:38:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0249.hostedemail.com [216.40.44.249]) by kanga.kvack.org (Postfix) with ESMTP id 359F5900002 for ; Mon, 18 May 2020 18:38:27 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E174A8248076 for ; Mon, 18 May 2020 22:38:26 +0000 (UTC) X-FDA: 76831305012.10.leg22_49b5cd05b815e X-HE-Tag: leg22_49b5cd05b815e X-Filterd-Recvd-Size: 4774 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Mon, 18 May 2020 22:38:26 +0000 (UTC) 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 3D63A2075F; Mon, 18 May 2020 22:38:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1589841505; bh=Sd5ezXE7qYEtfRiNzmhu3tUhZvaqR/4PPRmzDGYu5Ws=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=okjC93SPhXqlfE2cPpgu+8/zjH2CSFa7zpgRSSymDQGvYbn3J11Qud0fdC/Gi+2xJ HK4aT+bUN4P6Egn1DpDqPUS7UurC04TtA/ZNXtlEoGi8Flak8fH9QxWnmWgd7SLJ8V eZSlOZkxAjWY5WGl3br278Q61PyPtim2AXI8jeCA= Date: Mon, 18 May 2020 15:38:24 -0700 From: Andrew Morton To: Feng Tang Cc: Michal Hocko , Matthew Wilcox , Johannes Weiner , Mel Gorman , Kees Cook , 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 v3 3/3] mm: adjust vm_committed_as_batch according to vm overcommit policy Message-Id: <20200518153824.e4e57a651c6ca69fb8776dbc@linux-foundation.org> In-Reply-To: <1589611660-89854-4-git-send-email-feng.tang@intel.com> References: <1589611660-89854-1-git-send-email-feng.tang@intel.com> <1589611660-89854-4-git-send-email-feng.tang@intel.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, 16 May 2020 14:47:40 +0800 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 lift it to 64X for OVERCOMMIT_ALWAYS and OVERCOMMIT_GUESS policies. > Also add a sysctl handler to adjust it when the policy is reconfigured. > > Benchmark with the same testcase in [1] shows 53% improvement on a > 8C/16T desktop, and 2097%(20X) on a 4S/72C/144T server. We tested > with test platforms in 0day (server, desktop and laptop), and 80%+ > platforms shows improvements with that test. And whether it shows > improvements depends on if the test mmap size is bigger than the > batch number computed. > > And if the lift is 16X, 1/3 of the platforms will show improvements, > though it should help the mmap/unmap usage generally, 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. > " > This needed some adjustments to overcommit_policy_handler() after linux-next's 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler"). Relevant parts are below. --- a/include/linux/mm.h~mm-adjust-vm_committed_as_batch-according-to-vm-overcommit-policy +++ a/include/linux/mm.h @@ -205,6 +205,8 @@ int overcommit_ratio_handler(struct ctl_ loff_t *); int overcommit_kbytes_handler(struct ctl_table *, int, void *, size_t *, loff_t *); +int overcommit_policy_handler(struct ctl_table *, int, void *, size_t *, + loff_t *); #define nth_page(page,n) pfn_to_page(page_to_pfn((page)) + (n)) --- a/mm/util.c~mm-adjust-vm_committed_as_batch-according-to-vm-overcommit-policy +++ a/mm/util.c @@ -746,6 +746,18 @@ int overcommit_ratio_handler(struct ctl_ return ret; } +int overcommit_policy_handler(struct ctl_table *table, int write, void *buffer, + size_t *lenp, loff_t *ppos) +{ + int ret; + + ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos); + if (ret == 0 && write) + mm_compute_batch(); + + return ret; +} + int overcommit_kbytes_handler(struct ctl_table *table, int write, void *buffer, size_t *lenp, loff_t *ppos) { _