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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 64618EB64D7 for ; Fri, 23 Jun 2023 09:31:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B1868D0002; Fri, 23 Jun 2023 05:31:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 961B58D0001; Fri, 23 Jun 2023 05:31:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 829768D0002; Fri, 23 Jun 2023 05:31:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 73D2B8D0001 for ; Fri, 23 Jun 2023 05:31:29 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 4797A1C91CC for ; Fri, 23 Jun 2023 09:31:29 +0000 (UTC) X-FDA: 80933494698.09.3FBE989 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf07.hostedemail.com (Postfix) with ESMTP id E614640015 for ; Fri, 23 Jun 2023 09:31:25 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=jrEnDbSr; dkim=pass header.d=linutronix.de header.s=2020e header.b=PlFpMXvR; spf=pass (imf07.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687512686; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=GVj3EjpG0rSBEVTShFlEemvhWugXc5MZj9jgNgVMc9g=; b=LFfHY5I3Q1a5PbweEnlDgKMWGSng29fOx/COQENLCg9bS4kkV8CK400JPyn7VWffqVJbZ7 WuABm74dDvPGPmGWCC41EBHyK3PPlHQybwhRdpcR0naecdd7UEScxQ10352+c45pwhfhBB 4bdoIURploxnHJhAVic8R2D1WpHoj/8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687512686; a=rsa-sha256; cv=none; b=OS1pdxUqWPnL3ydHRhq9MerDoTskhBzvOfsK0qxsFPngTeR6Y1JUcXNvBpkZyhCBlvFy5K z20QerDpS4n/j0ZFkAtvDSPgs4USZ/NMJunv9w1N0G6ikWPxyDFEDN62JAvl7UqVOL1cd8 5uKSeQoJKGkDlIbvw3UutPqK2TgcXd0= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=jrEnDbSr; dkim=pass header.d=linutronix.de header.s=2020e header.b=PlFpMXvR; spf=pass (imf07.hostedemail.com: domain of bigeasy@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=bigeasy@linutronix.de; dmarc=pass (policy=none) header.from=linutronix.de Date: Fri, 23 Jun 2023 11:31:20 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1687512683; 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=GVj3EjpG0rSBEVTShFlEemvhWugXc5MZj9jgNgVMc9g=; b=jrEnDbSrvp/apiRPE0z700BHhBlut4Bad5idqEcaOr6OUYNz1ka3Oyml9sQSTcYkRkAURa JG9+yF+F1RzOGdJZCQ7kygTnJ63/xV3YOwe3MfVf6YjgNHdn/oEgfCNmPGbPzRFqtESBY3 EWw8Y077myE3+rVRS08GuFKCpjArzRIzdcv6p5o5Iu12pKqOvFcotN1nPHPYfVa53rlFjc aZq/9BEQWfAjA2d2WdSCISDOVXMnyjl9DWa6mWIp4gEfr0ZQeUYuahwaY19nXGNFB5FHPS bgF/5duZ1Ge0+8pvsIE1SOEZ442MYpCQmWGdk7jmiUNbluvAdcBF03ILOOAi+w== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1687512683; 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=GVj3EjpG0rSBEVTShFlEemvhWugXc5MZj9jgNgVMc9g=; b=PlFpMXvR6kdUhPuRdvk0BuQdQ3wBHkL5iAeaa3YCoX9DXCZzMYnyNn5EZt0kdg9zmfG4or Whfb3/+XORc0SsDQ== From: Sebastian Andrzej Siewior To: Tetsuo Handa Cc: Petr Mladek , linux-mm@kvack.org, "Luis Claudio R. Goncalves" , Andrew Morton , Mel Gorman , Michal Hocko , Thomas Gleixner Subject: Re: [PATCH] mm/page_alloc: Use write_seqlock_irqsave() instead write_seqlock() + local_irq_save(). Message-ID: <20230623093120.FR90BY7i@linutronix.de> References: <20230621104034.HT6QnNkQ@linutronix.de> <0e9fc992-8e05-2e63-b3b1-d8d3ce89fc16@I-love.SAKURA.ne.jp> <20230621130641.-5iueY1I@linutronix.de> <20230621143421.BgHjJklo@linutronix.de> <01031ffe-c81f-9cec-76fb-e70d548429cf@I-love.SAKURA.ne.jp> <8b6d3f39-c573-ca2b-957b-8c48c2fa68ad@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Stat-Signature: sumbufcs9as5zzp6ctdfqif7koje1aou X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: E614640015 X-Rspam-User: X-HE-Tag: 1687512685-182707 X-HE-Meta: U2FsdGVkX196whOxHoFiAuf36WJmkMQD5gM6y/sDUxr5WVUqWM/pch8w443Ap35Q0hh1SYKAsE+GvINGVEee9WSBWjojcqYZJpml2f4QRu092dkz2xUaQRY4PL00g96y1l3nxPa0MfhN/bzSrNDyCHAaMcX2/oVwdGd8BDSdlEgOhBmBDHB19EWTe97DkUIapUDG6GyENyFGobljQv1WrQ26kf6L/eSi1v2xZvDcNoa1GEjnzUtxzb241/9ScXOWjvdSmKSk6GCJkRiAPDKVt9JtrXexF67o3wfMXnmU4pvz225jdJmdDdfXQpJJjUIrgnF4EYrYX6fYIYklgzqdLjNcvhF0qfvs41xQf6+kIP9AtCEr1O274IFoIYgBZ2dl7yEiI1PUKt9QjB6q+DvVdgK7TPo2MnD7Yi2Er5m0WPd+eAkoTNBdeYEyFuRv2dr3Gh7UWx6y8/GJRBqaSat6mbAGrlSKuW+txEUl7+anGWMQLnE8AEX+XqHi4xkA9uTEcmGDTOXH31tDmXiiNYgU/4ur9ekJOdKlx2HE3IU6ezQlizb1xuxgne/kiHm9EmQeQuUZbH+1ohcj3eRPMGQ9q99WxWwPtH/RsQMJUvlbekI3sYZVNSJPRgKLOvnSPZC9jKSpl84baIZyQQQsy0XjQfWHzwXo1YoUH7Qk1bHRla0VXlmkNRuM5QtuZWNIcVaRGP+xHvuOCEKOYUqwXR4778cNGkI9wIWNPcei3/QzPQPQXPkdLTMqzjXDccm64GrFGmih3wliu9z8xOkE+wKCDCHGRLyk/p65ctnyDUnUoU2QiO2KHLfK16JjhDmxHcJe33zg6v8gxul1bnFlNCJ4HTRl2GC/dQA53BV0rcUtkOYbdtnVG4b2SMWeoFiztO+rRZOcfhGJVCR1gwbVq0J8b0QzP1j9vMKWAz1DuW88I458QxTEoiKdCFcx7PY+7Z1w9DU51eZeW208d4VjLfO EuxK4vpN m0B9jVhs30ARIAcI1YhIYBqvpR41uQtePsMBYkhtVlE8h5QABr3vyXVytL1VcVcxFZz6mA6F/nFZA467XMTlrB8ee+zbReJBZqftaNNVIoC9yU7FVpr/u0QSRzhDHH6WyLYASXcMPlaUcngzSK6FFvHzSTyhD7xTCQCMqKkDvAICpqaQ= 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 2023-06-22 22:36:27 [+0900], Tetsuo Handa wrote: > On 2023/06/22 8:24, Tetsuo Handa wrote: > > By the way, given > > > > write_seqlock_irqsave(&zonelist_update_seq, flags); > > <> > > some_timer_function() { > > kmalloc(GFP_ATOMIC); > > } > > <> > > printk_deferred_enter(); > > > > scenario in CONFIG_PREEMPT_RT=y case is handled by executing some_timer_function() > > on a dedicated kernel thread for IRQs, what guarantees that the kernel thread for > > IRQs gives up CPU and the user thread which called write_seqlock() gains CPU until > > write_sequnlock() is called? How can the kernel figure out that executing the user > > thread needs higher priority than the kernel thread? > > I haven't got response on this question. I did explain in 20230621143421.BgHjJklo@linutronix.de that the printk implementation is a different one on PREEMPT_RT. The reader _may_ boost the writer if needed. Also for !PREEMPT_RT your only concern was a lockdep splat within write_seqlock_irqsave() which I wanted to take care. Leaving that aside, I don't see any problem. > Several years ago, I demonstrated that a SCHED_IDLE priority userspace thread holding > oom_lock causes other concurrently allocating !SCHED_IDLE priority threads to > misunderstand that mutex_trylock(&oom_lock) failure implies we are making forward > progress (despite the SCHED_IDLE priority userspace thread was unable to wake up for > minutes). repeated trylock without explicit forward progress is a general problem on RT. We try to remove them where we find them. > If a SCHED_IDLE priority thread which called write_seqlock_irqsave() is preempted by > some other !SCHED_IDLE priority threads (especially realtime priority threads), and > such !SCHED_IDLE priority thread calls kmalloc(GFP_ATOMIC) or printk(), a similar thing > (misunderstand that spinning on read_seqbegin() from zonelist_iter_begin() can make > forward progress despite a thread which called write_seqlock_irqsave() cannot make > progress due to preemption) can happen. I can because on PREEMPT_RT the read_seqbegin() _will_ block on the lock, that is held by write_seqlock_irqsave(). This ensures that the writer will make progress and the reader does not loop several iterations like on !PREEMPT_RT. This is PREEMPT_RT and happens regardless of rhe priority of the task involved. > Question to Sebastian: > To make sure that such thing cannot happen, we should make sure that > a thread which entered write_seqcount_begin(&zonelist_update_seq.seqcount) from > write_seqlock_irqsave(&zonelist_update_seq, flags) can continue using CPU until > write_seqcount_end(&zonelist_update_seq.seqcount) from > write_seqlock_irqrestore(&zonelist_update_seq, flags). > Does adding preempt_disable() before write_seqlock(&zonelist_update_seq, flags) help? Es explained before, this scenario does not happen and is already accounted for by the underlying seqcount API. Adding preempt_disable() to the mix makes things worse. > Question to Peter: > Even if local_irq_save(flags) disables IRQ, NMI context can enqueue message via printk(). > When does the message enqueued from NMI context gets printed? If there is a possibility > that the message enqueued from NMI context gets printed between > "write_seqlock_irqsave(&zonelist_update_seq, flags) and printk_deferred_enter()" or > "printk_deferred_exit() and write_sequnlock_irqrestore(&zonelist_update_seq, flags)" ? > If yes, we can't increment zonelist_update_seq.seqcount before printk_deferred_enter()... There are no prints from NMI because you can't acquire a lock in NMI context. All printk invocations are delayed. Sebastian