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 60D77C433E1 for ; Fri, 31 Jul 2020 21:25:00 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 253FE22B42 for ; Fri, 31 Jul 2020 21:25:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="yrSee2rc" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 253FE22B42 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 A16E08D005D; Fri, 31 Jul 2020 17:24:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A3968D000B; Fri, 31 Jul 2020 17:24:59 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 869378D005D; Fri, 31 Jul 2020 17:24:59 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0149.hostedemail.com [216.40.44.149]) by kanga.kvack.org (Postfix) with ESMTP id 6C92F8D000B for ; Fri, 31 Jul 2020 17:24:59 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id EE820181AEF09 for ; Fri, 31 Jul 2020 21:24:58 +0000 (UTC) X-FDA: 77099651076.12.sense03_1c0659826f87 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id BE1FF18016EA8 for ; Fri, 31 Jul 2020 21:24:58 +0000 (UTC) X-HE-Tag: sense03_1c0659826f87 X-Filterd-Recvd-Size: 4399 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf19.hostedemail.com (Postfix) with ESMTP for ; Fri, 31 Jul 2020 21:24:58 +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 827402087C; Fri, 31 Jul 2020 21:24:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596230697; bh=6fS6WoCAB/9a/il66FyyY9S69DC1g+03XNy1dhsjylQ=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=yrSee2rcqjhyFiF8+MVpPHTFv1VekHD9on3KrC9mm3AlNQ4FPdiIzVHUzL+HFYwEz WBABzW3rgL1L1griCUr/8BYWcjWlhlF0o+db5WZ7W6IapBHIrRhPf08D3jlJYpMpu0 9n4FS0zBmwzFHM16VxlXaZfHUrQ9KLG5ym7qmfYk= Received: by paulmck-ThinkPad-P72.home (Postfix, from userid 1000) id 60F7735231D2; Fri, 31 Jul 2020 14:24:57 -0700 (PDT) Date: Fri, 31 Jul 2020 14:24:57 -0700 From: "Paul E. McKenney" To: Matthew Wilcox Cc: Andrew Morton , cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, hannes@cmpxchg.org, urezki@gmail.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: Raw spinlocks and memory allocation Message-ID: <20200731212457.GS9247@paulmck-ThinkPad-P72> Reply-To: paulmck@kernel.org References: <20200730231205.GA11265@paulmck-ThinkPad-P72> <20200731133834.517fdfee99b7ed2239f576aa@linux-foundation.org> <20200731204855.GR9247@paulmck-ThinkPad-P72> <20200731205933.GT23808@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200731205933.GT23808@casper.infradead.org> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: BE1FF18016EA8 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 Fri, Jul 31, 2020 at 09:59:33PM +0100, Matthew Wilcox wrote: > On Fri, Jul 31, 2020 at 01:48:55PM -0700, Paul E. McKenney wrote: > > On Fri, Jul 31, 2020 at 01:38:34PM -0700, Andrew Morton wrote: > > > On Thu, 30 Jul 2020 16:12:05 -0700 "Paul E. McKenney" wrote: > > > > > > > So, may we add a GFP_ flag that will cause kmalloc() and friends to return > > > > NULL when they would otherwise need to acquire their non-raw spinlock? > > > > This avoids adding any overhead to the slab-allocator fastpaths, but > > > > allows callback invocation to reduce cache misses without having to > > > > restructure some existing callers of call_rcu() and potential future > > > > callers of kfree_rcu(). > > > > > > We have eight free gfp_t bits so that isn't a problem. > > > > Whew!!! ;-) > > > > > Adding a test-n-branch to the kmalloc() fastpath may well be a concern. > > > > > > Which of mm/sl?b.c are affected? > > > > None of them, it turns out. The initial patch will instead directly > > invoke __get_free_page(). So we could just leave sl?b.c alone. > > Isn't that spelled GFP_NOWAIT? I don't think so in the current kernel, though I might be confused. The problem we are having isn't waiting, but rather normal spinlock_t acquisition. This does not count as waiting in !CONFIG_PREEMPT_RT kernels, and so there are code paths that acquire the non-raw zone_lock in rmqueue_bulk() even in the GFP_NOWAIT case. Because kfree_rcu() and call_rcu() and their callers might hold raw spinlocks, acquiring a non-raw spinlock is forbidden for them and for anything that they call, directly or indirectly. The reason for this restriction is that in -rt, the spin_lock(&zone->lock) in rmqueue_bulk() can sleep. This conversion of non-raw spinlocks to sleeplocks is part of how -rt reduces scheduling latency. Because acquiring a raw spinlock disables preemption (even in -rt), acquiring a non-raw spinlock while holding a raw spinlock gets you "scheduling while atomic" in -rt. And it will get you lockdep complaints in all kernels, not just -rt, when CONFIG_PROVE_RAW_LOCK_NESTING is enabled. And my guess is that CONFIG_PROVE_RAW_LOCK_NESTING=y will become the default sooner rather than later. But you are right that yet another approach might be modifying the GFP_NOWAIT handling so that it avoided acquiring non-raw spinlocks. However, evaluating that option requires quite a bit more knowledge of MM than I have! ;-) Thanx, Paul