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=-1.0 required=3.0 tests=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 017E8C433DF for ; Wed, 24 Jun 2020 09:47:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C01082088E for ; Wed, 24 Jun 2020 09:47:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C01082088E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 53C396B0008; Wed, 24 Jun 2020 05:47:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5129E6B000A; Wed, 24 Jun 2020 05:47:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DBA36B000C; Wed, 24 Jun 2020 05:47:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 28AE56B0008 for ; Wed, 24 Jun 2020 05:47:35 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E04EE180AD830 for ; Wed, 24 Jun 2020 09:47:34 +0000 (UTC) X-FDA: 76963628028.17.crate16_59089b526e43 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id B2EB9180D0180 for ; Wed, 24 Jun 2020 09:47:34 +0000 (UTC) X-HE-Tag: crate16_59089b526e43 X-Filterd-Recvd-Size: 6358 Received: from mail-ed1-f66.google.com (mail-ed1-f66.google.com [209.85.208.66]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Wed, 24 Jun 2020 09:47:34 +0000 (UTC) Received: by mail-ed1-f66.google.com with SMTP id g20so797718edm.4 for ; Wed, 24 Jun 2020 02:47:34 -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=cqm5YdZPoz5wJCxaVvTakbtXbCTl+ojhxu7NcntLAOg+v2XVarfqRCOWC3rQDHbFgO q+Ns/aEU8PC3gWTTGasu7+Q/4PvTGpvXX0xVZZTTL/xOSsixqPFQ8RKHawP0emZUmlDG 47rUMmpVYlR9f4HDgnm8aW0bVogS3PhpqMqIp5MZ0BbDciy6GQuxUtCLNfCuPxm3S1JP 885wti2bQ6VCxTJXUN2DZgQR5ts0gWs8WYjMVCdqTqt5rjQhsHV9UGX0KmHHBwrJqdYD AMr9DKXVsnPWvwKC0xYDMF95PUPN6SnKL+aVCkfflgI7zOz3RaocHgZcRShVbliMVQZn iOtA== X-Gm-Message-State: AOAM530hVGiMSIIMkJg0mHr5XfRvu7+UcBrNIIVHZ5w6Hek2iy/GMmFI mFrSIaQq+vntuCOzqaJWE5Y= X-Google-Smtp-Source: ABdhPJzMLr63mqGrkFdxdRTARyOnbogYQGWZNhsvMCY17e7Zt06rYikB9+H4/+7lUOw2QkbuquWIYQ== 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> X-Rspamd-Queue-Id: B2EB9180D0180 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam01 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: 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