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.8 required=3.0 tests=BAYES_00, 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 B47A6C433DF for ; Mon, 17 Aug 2020 08:47:23 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8423420758 for ; Mon, 17 Aug 2020 08:47:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8423420758 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CDC846B0003; Mon, 17 Aug 2020 04:47:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C8D2F6B0005; Mon, 17 Aug 2020 04:47:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BC92A6B0006; Mon, 17 Aug 2020 04:47:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0167.hostedemail.com [216.40.44.167]) by kanga.kvack.org (Postfix) with ESMTP id A6CE96B0003 for ; Mon, 17 Aug 2020 04:47:22 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 51403181AEF39 for ; Mon, 17 Aug 2020 08:47:22 +0000 (UTC) X-FDA: 77159431524.22.year88_26016d227015 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id 20F291802EC84 for ; Mon, 17 Aug 2020 08:47:22 +0000 (UTC) X-HE-Tag: year88_26016d227015 X-Filterd-Recvd-Size: 4129 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Mon, 17 Aug 2020 08:47:21 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 5E9B4AE8C; Mon, 17 Aug 2020 08:47:45 +0000 (UTC) Date: Mon, 17 Aug 2020 10:47:19 +0200 From: Michal Hocko To: Thomas Gleixner Cc: paulmck@kernel.org, Uladzislau Rezki , LKML , RCU , linux-mm@kvack.org, Andrew Morton , Vlastimil Babka , Matthew Wilcox , "Theodore Y . Ts'o" , Joel Fernandes , Sebastian Andrzej Siewior , Oleksiy Avramchenko , Peter Zijlstra Subject: Re: [RFC-PATCH 1/2] mm: Add __GFP_NO_LOCKS flag Message-ID: <20200817084719.GB28270@dhcp22.suse.cz> References: <20200814180141.GP4295@paulmck-ThinkPad-P72> <87tux4kefm.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87tux4kefm.fsf@nanos.tec.linutronix.de> X-Rspamd-Queue-Id: 20F291802EC84 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 Sat 15-08-20 01:14:53, Thomas Gleixner wrote: [...] > For normal operations a couple of pages which can be preallocated are > enough. What you are concerned of is the case where you run out of > pointer storage space. > > There are two reasons why that can happen: > > 1) RCU call flooding > 2) RCU not being able to run and mop up the backlog > > #1 is observable by looking at the remaining storage space and the RCU > call frequency > > #2 is uninteresting because it's caused by RCU being stalled / delayed > e.g. by a runaway of some sorts or a plain RCU usage bug. > > Allocating more memory in that case does not solve or improve anything. > > So the interesting case is #1. Which means we need to look at the > potential sources of the flooding: > > 1) User space via syscalls, e.g. open/close > 2) Kernel thread > 3) Softirq > 4) Device interrupt > 5) System interrupts, deep atomic context, NMI ... > > #1 trivial fix is to force switching to an high prio thread or a soft > interrupt which does the allocation > > #2 Similar to #1 unless that thread loops with interrupts, softirqs or > preemption disabled. If that's the case then running out of RCU > storage space is the least of your worries. > > #3 Similar to #2. The obvious candidates (e.g. NET) for monopolizing a > CPU have loop limits in place already. If there is a bug which fails > to care about the limit, why would RCU care and allocate more memory? > > #4 Similar to #3. If the interrupt handler loops forever or if the > interrupt is a runaway which prevents task/softirq processing then > RCU free performance is the least of your worries. > > #5 Clearly a bug and making RCU accomodate for that is beyond silly. > > So if call_rcu() detects that the remaining storage space for pointers > goes below the critical point or if it observes high frequency calls > then it simply should force a soft interrupt which does the allocation. > > Allocating from softirq context obviously without holding the raw lock > which is used inside call_rcu() is safe on all configurations. > > If call_rcu() is forced to use the fallback for a few calls until this > happens then that's not the end of the world. It is not going to be a > problem ever for the most obvious issue #1, user space madness, because > that case cannot delay the softirq processing unless there is a kernel > bug which makes again RCU free performance irrelevant. Yes, this makes perfect sense to me! I really do not think we want to optimize for a userspace abuse to allow complete pcp allocator memory depletion (or a control in a worse case). Thanks! -- Michal Hocko SUSE Labs