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,URIBL_BLOCKED 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 232C3C433E0 for ; Wed, 1 Jul 2020 10:06:03 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D935520722 for ; Wed, 1 Jul 2020 10:06:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D935520722 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 825468D0032; Wed, 1 Jul 2020 06:06:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7D5268D002B; Wed, 1 Jul 2020 06:06:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C3F08D0032; Wed, 1 Jul 2020 06:06:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0176.hostedemail.com [216.40.44.176]) by kanga.kvack.org (Postfix) with ESMTP id 56AA28D002B for ; Wed, 1 Jul 2020 06:06:02 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1695B8248076 for ; Wed, 1 Jul 2020 10:06:02 +0000 (UTC) X-FDA: 76989076164.03.pets41_130373226e7f Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id C98A128A240 for ; Wed, 1 Jul 2020 10:06:01 +0000 (UTC) X-HE-Tag: pets41_130373226e7f X-Filterd-Recvd-Size: 5077 Received: from mail-ej1-f68.google.com (mail-ej1-f68.google.com [209.85.218.68]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Wed, 1 Jul 2020 10:06:01 +0000 (UTC) Received: by mail-ej1-f68.google.com with SMTP id o18so19474111eje.7 for ; Wed, 01 Jul 2020 03:06:01 -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=rsUj7DlBZ6M+wGKkVIdI5HybWRoDhFOjqUHfmhTwGG8=; b=el62wZXCXvnqNUdUsKq6SE64Oqvp38u7pN0BS+zXjA6nNVq6acqx1N8YCnHFeT8Elu M8eXy6R5D2u0fMrTQzqn1qRMJf+1fmIDC1yRcqrKSnXL+QvbqGdFGiiiouZeVPcqMC4P nihkWRoAoh7lt+3N+OKTuKrn7CGJVDbGjI6vScFBnIGaAL+rLkXC28TlVPlhnvQOV2V5 bmfLiPWKtIhn9UNcCownMz8fmSzuZUyUyktJPfp2N2CvfklRC2s99PNxlY/ScvOiDQ8V aaGA11+OqdKC41Iay9MoSluy+YWZykdKJdYPL8C4/4ecZIik3cI69qvBkfYwj5D3L1vw Xhsw== X-Gm-Message-State: AOAM530RrelxpweSM61iakJnjYM4wV47VKZMDW03DQs6TkyfqF1aj46T cLclz3T7I/iQwtLlLsjPppk= X-Google-Smtp-Source: ABdhPJxusZx5FwVct6q6aR0tnn/SkBmxrGo0c3NRy+df/P1khhDPjjeet6irL5Jib8wS59WKdA3txQ== X-Received: by 2002:a17:906:ecb3:: with SMTP id qh19mr10499598ejb.273.1593597960160; Wed, 01 Jul 2020 03:06:00 -0700 (PDT) Received: from localhost (ip-37-188-168-3.eurotel.cz. [37.188.168.3]) by smtp.gmail.com with ESMTPSA id r17sm5659343edw.68.2020.07.01.03.05.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 01 Jul 2020 03:05:59 -0700 (PDT) Date: Wed, 1 Jul 2020 12:05:57 +0200 From: Michal Hocko To: Andrew Morton Cc: Tim Chen , Matthew Wilcox , Vladimir Davydov , Johannes Weiner , Dave Hansen , Ying Huang , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [Patch] mm: Increase pagevec size on large system Message-ID: <20200701100557.GQ2369@dhcp22.suse.cz> References: <20200627031304.GC25039@casper.infradead.org> <20200626204704.f023988699421db00e9bdab7@linux-foundation.org> <6260c66e-68a3-ab3e-4bd9-4a290d068e1f@linux.intel.com> <20200630172713.496590a923744c0e0160d36b@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200630172713.496590a923744c0e0160d36b@linux-foundation.org> X-Rspamd-Queue-Id: C98A128A240 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 Tue 30-06-20 17:27:13, Andrew Morton wrote: > On Mon, 29 Jun 2020 09:57:42 -0700 Tim Chen wrote: > > I am okay with Matthew's suggestion of keeping the stack pagevec size unchanged. > > Andrew, do you have a preference? > > > > I was assuming that for people who really care about saving the kernel memory > > usage, they would make CONFIG_NR_CPUS small. I also have a hard time coming > > up with a better scheme. > > > > Otherwise, we will have to adjust the pagevec size when we actually > > found out how many CPUs we have brought online. It seems like a lot > > of added complexity for going that route. > > Even if we were to do this, the worst-case stack usage on the largest > systems might be an issue. If it isn't then we might as well hard-wire > it to 31 elements anyway, I am not sure this is really a matter of how large the machine is. For example in the writeout paths this really depends on how complex the IO stack is much more. Direct memory reclaim is also a very sensitive stack context. As we are not doing any writeout anymore I believe a large part of the on stack fs usage is not really relevant. There seem to be only few on stack users inside mm and they shouldn't be part of the memory reclaim AFAICS. I have simply did $ git grep "^[[:space:]]*struct pagevec[[:space:]][^*]" and fortunately there weren't that many hits to get an idea about the usage. There is some usage in the graphic stack that should be double check though. Btw. I think that pvec is likely a suboptimal data structure for many on stack users. It allows only very few slots to batch. Something like mmu_gather which can optimistically increase the batch sounds like something that would be worth The main question is whether the improvement is visible on any non-artificial workloads. If yes then the quick fix is likely the best way forward. If this is mostly a microbench thingy then I would be happier to see a more longterm solution. E.g. scale pcp pagevec sizes on the machine size or even use something better than pvec (e.g. lru_deactivate_file could scale much more and I am not sure pcp aspect is really improving anything - why don't we simply invalidate all gathered pages at once at the end of invalidate_mapping_pages?). -- Michal Hocko SUSE Labs