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 B0AF4EB64D7 for ; Wed, 21 Jun 2023 14:34:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 452188D0003; Wed, 21 Jun 2023 10:34:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3DA528D0002; Wed, 21 Jun 2023 10:34:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 254768D0003; Wed, 21 Jun 2023 10:34:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 10A8E8D0002 for ; Wed, 21 Jun 2023 10:34:29 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D84E01C8401 for ; Wed, 21 Jun 2023 14:34:28 +0000 (UTC) X-FDA: 80927000616.02.D5B657B Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf24.hostedemail.com (Postfix) with ESMTP id F0F71180012 for ; Wed, 21 Jun 2023 14:34:25 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=H7UDGtAK; dkim=pass header.d=linutronix.de header.s=2020e header.b=V+nBrUmW; spf=pass (imf24.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=1687358066; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5tQMG95rT8PissMPtXZHbrF4zVoM0bNLPUvZwG4KGeA=; b=e9tUhHUymUNAUw7DJcxNKNxpRmnFuiIqzrbQtSTuu6EPr5rAz7MkdJqKbz+NmNfL2DFnEb LPuwJtPmMsgm4m/UAF7OzAcqmoTmfRAoQyPK+MkPJpjOFM3S/ZV8yGHEIfZxn67gYQ7vqL d/n2NYBMTmdzCz2U3eFh9qz/q14+Vnk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687358066; a=rsa-sha256; cv=none; b=4GznntPjugsdME+7E0vfIPCGE5adI5H00Cd3bptVeixnIKZ30U7ILBvgEo6pLzUIDBz5DE yBWKg5AGtMx5H4u70IoiZ6o2nzCXaBLDrojkz5x4bVT5VtN9ZlQelBEAfis/IGc2piiPNr DzOyfThAn5viPY4Ln0Pk5ZNyIbDoX4w= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=H7UDGtAK; dkim=pass header.d=linutronix.de header.s=2020e header.b=V+nBrUmW; spf=pass (imf24.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: Wed, 21 Jun 2023 16:34:21 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1687358063; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5tQMG95rT8PissMPtXZHbrF4zVoM0bNLPUvZwG4KGeA=; b=H7UDGtAK5IVVbXC0PpodkMWGnS5H+31Rj1XOIxVJ5l1mcftiz4iGdZQ/uPUUsNepQGglUV uUEZwSliMl4gDJbBND30s97mU2kfIEe3WDdUs2fIYHvndNaoRIq6R6CcY6D4PdN/t9vIN9 YPF5doewGGkpuQcMQvnXwR/4IY2069MW3tW6DqDkMw/PAKsctc56nKaFsGmpqNG+TWBR9n yLzeXUbzwQsXSZ/ef+ma5v65BWutF53CqvymyYO9QVu7kv/dpr3YDROFL9SR1QRCo8fB7O kG8VEywbIXNdnFjxpBtzF34AfR0AvmkXNkH9JUa+dE+0XV+teRkLLNvMUUqBKw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1687358063; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=5tQMG95rT8PissMPtXZHbrF4zVoM0bNLPUvZwG4KGeA=; b=V+nBrUmWA5m72ta3f/HhPwHXjAuxnVRXk+au/vgkJr5cunuVho4y/KNKAUZHta1I/GGM07 KtIoUgtzM8BGCLAQ== From: Sebastian Andrzej Siewior To: Tetsuo Handa Cc: linux-mm@kvack.org, "Luis Claudio R. Goncalves" , Andrew Morton , Mel Gorman , Michal Hocko , Thomas Gleixner , Petr Mladek Subject: Re: [PATCH] mm/page_alloc: Use write_seqlock_irqsave() instead write_seqlock() + local_irq_save(). Message-ID: <20230621143421.BgHjJklo@linutronix.de> References: <20230621104034.HT6QnNkQ@linutronix.de> <0e9fc992-8e05-2e63-b3b1-d8d3ce89fc16@I-love.SAKURA.ne.jp> <20230621130641.-5iueY1I@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: X-Stat-Signature: fn7r6o9pw3y6ywwx5q1mjjgozgeb3jgw X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: F0F71180012 X-Rspam-User: X-HE-Tag: 1687358065-710561 X-HE-Meta: U2FsdGVkX18Idg5GLgMsOt/P7Rlu2Kg0W3TM+9lnlbIKjtmX0qIf6JcAfl6fDo5ViF8TGUmS4pv0sfn/bwHwI7l5k62zDDUsTTKxHxnWaAtee+eaY+nQXqh6r88KThIbilXMqtzvwzLZWY/3Fe5WMOG3894gM+IOVgCbuIqOGufPVgCcKHftJcFmORrRH9eRArmgnD7go/4Gxh5/CPBvhB0WdKFpdLC8XrtOocbmLTk+tLl01fG+JdVOE/BsgrLo9HZ7kMt/SqAKdUYyJ2wA+9UpK2EGqoIAuMCdx5jiip9uZF6HvGBTrU3EetOGT0uSzpix6nZ2QhFXkZ3KrA0p/KIRAmoDaIf2RM85uFJaFUqDpKpLXiiB7Ydq84QL+7/q4mKXsRKTCKn/huVtMAo30NyFeOPXZDFdB/vwxsfuAYKLwwjyjasu7pcIsHrubR4dV03LtpIW7UQFzTgZ+BzF7+yvMi5jmzoRPYORtaS0geOauSGPyguSqfNvjJwPr5r/Zrg6TFc2WCRPzy+8I5diZb3GW/lUZ0YmR4gkdGJ9aO34mG3HibfYX14j5Vxve2+1wz4UmifkV1gVSDhTWJefaZSJaX4+g8T4ek1vF28Cn2w8byPYv4kaKVA3EwzBPiJ8uxTkqoJosrlsCcRl4kXCEbCjnMTCLg+cux15KS0fkOkardk+BzhYne1TCl1sL+rYLiJ1jbXxF+tAVQ+ZOE5cUgQo9dh6kj+wvWOrxEKBedOe8iA5Ma8eXydLJwjkSwayULXEegjx0DocBowzmKrsRwneu4CrRzp5Kapl3C38BXLvOGzPgkrvx/+XBZykDdIfVM9netEwZvCAGEvNY6Ym0G8cAySjn/u78LRIH0tIgL60L5cLKMuVb3xOllYHJyiRQlOanus4Em8d4EWIQhDIBJz2bjV3cyoXLDzLpfxr5znMAy04RQEGNK3AYj2eGOWSAxe+2iO05LkQDX74hMd TfgCaKV7 46zwmDCvopQPh7XoK3Wj0cp9X1WXuPu3FUIowAHDt6d5GrjtM2J3tpZlqvazlXXKEWwp/rSquoxzAlbgJNq6qi3/sHdPLPNPn9nYcgX2MkTeF8O2RF9hr1sTNobtuuCWkm2epvljghuMEAmA= 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-21 22:32:40 [+0900], Tetsuo Handa wrote: > include/linux/seqlock.h says =E2=80=A6 > Is above understanding correct? That is correct. > And you are trying to replace >=20 > local_irq_save(flags); > printk_deferred_enter(); > write_seqlock(&zonelist_update_seq); >=20 > with >=20 > write_seqlock_irqsave(&zonelist_update_seq, flags); > printk_deferred_enter(); >=20 > , aren't you? correct. > But include/linux/printk.h says >=20 > /* > * The printk_deferred_enter/exit macros are available only as a hack f= or > * some code paths that need to defer all printk console printing. Inte= rrupts > * must be disabled for the deferred duration. > */ > #define printk_deferred_enter __printk_safe_enter > #define printk_deferred_exit __printk_safe_exit >=20 > which means that local_irq_save() is _required_ before printk_deferred_en= ter(). It says that, yes, but that requirement is described as too heavy. The requirement is that printk_deferred_enter() happens on the same CPU as printk_deferred_exit(). This can be achieved by an explicit local_irq_save(), yes, but also by something like spin_lock_irq() which _ensures_ that the task does not migrate to another CPU while the lock is acquired. This is the requirement by the current implementation. > If local_irq_save() is hidden by your patch, what guarantees that > printk_deferred_enter() and printk_deferred_exit() run on the same CPU? Because spin_lock_irqsave() on CONFIG_PREEMPT_RT uses migrate_disable(). The function ensures that the scheduler does not migrate the task to another CPU. The CPU is even block from going down (as in CPU-hotplug) until the matching migrate_enable() occurs. > Also, if local_irq_save() is hidden due to RT, what guarantees that >=20 > write_seqlock_irqsave(&zonelist_update_seq, flags); > <> > some_timer_function() { > printk(); > } > <> > printk_deferred_enter(); > > does not happen because write_seqlock_irqsave() does not disable IRQ? I don't see how zonelist_update_seq and printk here are connected without the port lock/ or memory allocation. But there are two things that are different on RT which probably answer your question: - If the reader observes an odd sequence number then it acquires the lock of the sequence counter (it is held by the writer) which forces the writer to complete the write critical section and then the reader can continue. There are _no_ memory allocation within a hard IRQ context (as in the actual interrupt). The timer (hrtimer or timer_list timer) are served in task context and we have forced-threaded interrupts. Clearly this means that the seqlock_t (as used here) can only be used task context and not in hard IRQ context. - The printk implementation is slightly different and it is being worked to merge it upstream. The two important differences here: - Printing happens by default in a dedicated printing thread. - In emergency cases like panic(), printing happens directly within the invocation of printk(). This requires a so called atomic console which does not use the tty_port::lock. > Disabling IRQ before incrementing zonelist_update_seq is _required_ for b= oth >=20 > making printk_deferred_enter() safe >=20 > and >=20 > making sure that printk_deferred_enter() takes effect >=20 > . Did I explain why it is sufficient to do write_seqlock_irqsave() printk_deferred_enter() assuming we have | static inline void do_write_seqcount_begin_nested(seqcount_t *s, int subc= lass) | { | seqcount_acquire(&s->dep_map, subclass, 0, _RET_IP_); | do_raw_write_seqcount_begin(s); | } ? Sebastian