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=-3.9 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 CF361C433DF for ; Tue, 18 Aug 2020 16:55:18 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 93D6320786 for ; Tue, 18 Aug 2020 16:55:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="WMLTCK9u"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="cq931B0s" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 93D6320786 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linutronix.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1317E8D002B; Tue, 18 Aug 2020 12:55:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E15F8D0001; Tue, 18 Aug 2020 12:55:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F123A8D002B; Tue, 18 Aug 2020 12:55:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0108.hostedemail.com [216.40.44.108]) by kanga.kvack.org (Postfix) with ESMTP id D7DF38D0001 for ; Tue, 18 Aug 2020 12:55:17 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 72B4A181AEF15 for ; Tue, 18 Aug 2020 16:55:17 +0000 (UTC) X-FDA: 77164289874.27.trick59_1b0f47727020 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin27.hostedemail.com (Postfix) with ESMTP id 436F63D669 for ; Tue, 18 Aug 2020 16:55:17 +0000 (UTC) X-HE-Tag: trick59_1b0f47727020 X-Filterd-Recvd-Size: 4320 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Tue, 18 Aug 2020 16:55:15 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1597769713; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lRnA/wasNgt3N1fOKKFjakzmrR8m48bxdaoauNatP3I=; b=WMLTCK9uMaYgN+l7nWqHD2RZlhiOVHeMfR+WGDgzx7CjDUeFIRxMgE22yIqCf4mcKNyHwM 9/cKXIQ7M4axoMfKcRyvNo4/wPTgS0H8OyLj3t6bmJ2mbzD+0w3NvFxjJ518L8/Yoy7tGF TCLKsgK3usKaFcVbnlhKCOJJV1C+QJX8A4+oy1VONa4+/i/BEaSgeclwKKwycjwMnD+ryV H0Bu+2pK13HFVNXRzw1ataV8UQSDXF6A22WcRUcLitnJOOhSaYE4l3Hu4XZkUCEP2ywfgb PTlTBn7WDFILkctisJnteQbqejQ3T9dcDLMM1Q6DdsqfgIaiN+ABla1LezigQQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1597769713; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lRnA/wasNgt3N1fOKKFjakzmrR8m48bxdaoauNatP3I=; b=cq931B0s0KrRKYyMcgIduqaVhFjJeVhJd3kRc3jIKHt3L05AH0m7TDRSuR9+X/p+MDZuUZ zvbuxNAtsMH2pdAQ== To: paulmck@kernel.org Cc: Michal Hocko , Uladzislau Rezki , Peter Zijlstra , 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 In-Reply-To: <20200818161355.GE27891@paulmck-ThinkPad-P72> References: <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> <20200817222803.GE23602@paulmck-ThinkPad-P72> <20200818074344.GL28270@dhcp22.suse.cz> <20200818135327.GF23602@paulmck-ThinkPad-P72> <87o8n8hv5p.fsf@nanos.tec.linutronix.de> <20200818161355.GE27891@paulmck-ThinkPad-P72> Date: Tue, 18 Aug 2020 18:55:11 +0200 Message-ID: <87lfibj3m8.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain X-Rspamd-Queue-Id: 436F63D669 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam05 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, Aug 18 2020 at 09:13, Paul E. McKenney wrote: > On Tue, Aug 18, 2020 at 04:43:14PM +0200, Thomas Gleixner wrote: >> On Tue, Aug 18 2020 at 06:53, Paul E. McKenney wrote: >> > On Tue, Aug 18, 2020 at 09:43:44AM +0200, Michal Hocko wrote: >> >> Thomas had a good point that it doesn't really make much sense to >> >> optimize for flooders because that just makes them more effective. >> > >> > The point is not to make the flooders go faster, but rather for the >> > system to be robust in the face of flooders. Robust as in harder for >> > a flooder to OOM the system. >> > >> > And reducing the number of post-grace-period cache misses makes it >> > easier for the callback-invocation-time memory freeing to keep up with >> > the flooder, thus avoiding (or at least delaying) the OOM. >> >> Throttling the flooder is incresing robustness far more than reducing >> cache misses. > > True, but it takes time to identify a flooding event that needs to be > throttled (as in milliseconds). This time cannot be made up. Not really. A flooding event will deplete your preallocated pages very fast, so you have to go into the allocator and get new ones which naturally throttles the offender. So if your open/close thing uses the new single argument free which has to be called from sleepable context then the allocation either gives you a page or that thing has to wait. No fancy extras. You still can have a page reserved for your other regular things and once that it gone, you have to fall back to the linked list for those. But when that happens the extra cache misses are not your main problem anymore. Thanks, tglx