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.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 AB4C2C433EA for ; Mon, 17 Aug 2020 22:28:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5120C2072D for ; Mon, 17 Aug 2020 22:28:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="z2inuekb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5120C2072D 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 95F626B0002; Mon, 17 Aug 2020 18:28:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 917AC6B0005; Mon, 17 Aug 2020 18:28:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7D5FA6B0006; Mon, 17 Aug 2020 18:28:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0103.hostedemail.com [216.40.44.103]) by kanga.kvack.org (Postfix) with ESMTP id 63F0F6B0002 for ; Mon, 17 Aug 2020 18:28:06 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1E8B3181AEF09 for ; Mon, 17 Aug 2020 22:28:06 +0000 (UTC) X-FDA: 77161499772.06.humor21_39135e22701a Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id D8F26100495E7 for ; Mon, 17 Aug 2020 22:28:05 +0000 (UTC) X-HE-Tag: humor21_39135e22701a X-Filterd-Recvd-Size: 4901 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Mon, 17 Aug 2020 22:28:05 +0000 (UTC) Received: from paulmck-ThinkPad-P72.home (unknown [50.45.173.55]) (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 5AC39204EC; Mon, 17 Aug 2020 22:28:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1597703284; bh=NUONv9kLCShilfn9ZT/o30cFFqVc/L2+Z/w6nr7C0zk=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=z2inuekbTwOWe5b25wv8EliIvOxNuBYdsAw0rDxdv8Tx1PeutqY/VjF5lmu44RB7h 11nUJyqzMMgH8lXsbxK2+PVorRtEXuGvPQXRL5rtuxd2GNLaKnBPuwzPIHkYG9klAk kKI2Pc2NooJe/okdbcRDEET3yYg5bItBBn++/0jQ= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id DA17C3522617; Mon, 17 Aug 2020 15:28:03 -0700 (PDT) Date: Mon, 17 Aug 2020 15:28:03 -0700 From: "Paul E. McKenney" To: Michal Hocko Cc: Uladzislau Rezki , Peter Zijlstra , Thomas Gleixner , LKML , RCU , linux-mm@kvack.org, Andrew Morton , Vlastimil Babka , Matthew Wilcox , "Theodore Y . Ts'o" , Joel Fernandes , Sebastian Andrzej Siewior , Oleksiy Avramchenko Subject: Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag Message-ID: <20200817222803.GE23602@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org References: <20200814083037.GD3982@worktop.programming.kicks-ass.net> <20200814141425.GM4295@paulmck-ThinkPad-P72> <20200814161106.GA13853@paulmck-ThinkPad-P72> <20200814174924.GI3982@worktop.programming.kicks-ass.net> <20200814180224.GQ4295@paulmck-ThinkPad-P72> <875z9lkoo4.fsf@nanos.tec.linutronix.de> <20200814204140.GT4295@paulmck-ThinkPad-P72> <20200814215206.GL3982@worktop.programming.kicks-ass.net> <20200816225655.GA17869@pc636> <20200817082849.GA28270@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200817082849.GA28270@dhcp22.suse.cz> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: D8F26100495E7 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Mon, Aug 17, 2020 at 10:28:49AM +0200, Michal Hocko wrote: > On Mon 17-08-20 00:56:55, Uladzislau Rezki wrote: [ . . . ] > > wget ftp://vps418301.ovh.net/incoming/1000000_kmalloc_kfree_rcu_proc_percpu_pagelist_fractio_is_8.png > > 1/8 of the memory in pcp lists is quite large and likely not something > used very often. > > Both these numbers just make me think that a dedicated pool of page > pre-allocated for RCU specifically might be a better solution. I still > haven't read through that branch of the email thread though so there > might be some pretty convincing argments to not do that. To avoid the problematic corner cases, we would need way more dedicated memory than is reasonable, as in well over one hundred pages per CPU. Sure, we could choose a smaller number, but then we are failing to defend against flooding, even on systems that have more than enough free memory to be able to do so. It would be better to live within what is available, taking the performance/robustness hit only if there isn't enough. My current belief is that we need a combination of (1) either the GFP_NOLOCK flag or Peter Zijlstra's patch and (2) Thomas Gleixner's delayed allocation approach. As you say and as Uladislau's measurements suggest, if we only have Peter's approach, although we could handle short floods just fine, we could not handle longer-term floods. And Thomas's approach is in fact designed to handle these longer-term floods. Except that if we have only Thomas's approach, then we have to handle the possibility that RCU_SOFTIRQ happened on the back of an interrupt that happened while the interrupted process was holding a memory-allocator lock. This means further deferral, such as going into a workqueue, which would allow better memory-allocator results, but which would also mean further delays from the time that memory was needed until the time that it was actually supplied. Delays that could be bridged by either a GFP_NOLOCK flag or Peter's patch. So again, it looks like this is not an either/or situation, but rather an need-both situation. I freely confess that one of my hopes almost 30 years ago was that a high-quality parallel memory allocator would eliminate the need for special-purpose allocators, but as has been noted several times on this thread, reality does not always seem to be compelled to take such hopes into account. Thanx, Paul