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 4D84CEB64D7 for ; Fri, 23 Jun 2023 10:40:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BBB6A8D0002; Fri, 23 Jun 2023 06:40:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B6B318D0001; Fri, 23 Jun 2023 06:40:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5B0C8D0002; Fri, 23 Jun 2023 06:40:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 9959D8D0001 for ; Fri, 23 Jun 2023 06:40:31 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 61A591C9354 for ; Fri, 23 Jun 2023 10:40:31 +0000 (UTC) X-FDA: 80933668662.24.0BE50A7 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf08.hostedemail.com (Postfix) with ESMTP id 3AB7E160024 for ; Fri, 23 Jun 2023 10:40:27 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=TdXoOlMn; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf08.hostedemail.com: domain of pmladek@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=pmladek@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687516828; 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=M+G8MX/6LEs6upuPzQfYBuwd0PK/wr0LI3VNpdNWHmU=; b=uyEeZtte8VrFmQjunQMIcL3MtfC1J9ppCkHupx+FTk8m0hWsgIRPTlwGzGjIC4MGjH5eKP 1k3B0RmdAZfS/MYOc2ajLLK+TMovAKyVG7fawyNDWp/xEX9k28frpsyGvPxhGDj78bcQyk 66Qq07d3SZS2CcfVkVkY/0ZxFLOvlFo= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=TdXoOlMn; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf08.hostedemail.com: domain of pmladek@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=pmladek@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687516828; a=rsa-sha256; cv=none; b=nTEMivlXh3nuuve0letw7JWKJJLdx4IMu9Tlq/cnwdBmhgjEyqj/5JWzXXapoz6gBV+bUs AdpkkFn6Cr94IiWeLJ8P/hPzWG9Gp0Ljx8xBvJ+6oqxC/QwEXXPddL9rfmdhWkrTWC/+Gf n9bKZ1Dig42AfbPFu8cVbXY+oI68r2Q= Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 71E47215EF; Fri, 23 Jun 2023 10:40:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1687516826; h=from:from:reply-to: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=M+G8MX/6LEs6upuPzQfYBuwd0PK/wr0LI3VNpdNWHmU=; b=TdXoOlMnK9zmf2OlnJ+Oih8WCa+0m7q/HzGvnmxMu/dwJseO3p86wKG+pclluV4glnfwYC 0GhjQfZec23XXkmEVKPaSID7pBTudpmoKW82gYPGSnZZPkHhUu5pj24QdDA1HFabrr4MV4 Cb0MEpB3uvUk35AF+fBsP8031KEQ57E= Received: from suse.cz (unknown [10.100.201.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id F255B2C141; Fri, 23 Jun 2023 10:40:24 +0000 (UTC) Date: Fri, 23 Jun 2023 12:40:24 +0200 From: Petr Mladek To: Sebastian Andrzej Siewior Cc: Tetsuo Handa , linux-mm@kvack.org, "Luis Claudio R. Goncalves" , Andrew Morton , Mel Gorman , Michal Hocko , Thomas Gleixner , John Ogness Subject: Re: [PATCH] mm/page_alloc: Use write_seqlock_irqsave() instead write_seqlock() + local_irq_save(). Message-ID: References: <20230621104034.HT6QnNkQ@linutronix.de> <0e9fc992-8e05-2e63-b3b1-d8d3ce89fc16@I-love.SAKURA.ne.jp> <20230621130641.-5iueY1I@linutronix.de> <20230621143421.BgHjJklo@linutronix.de> <20230623081250.h20rlLik@linutronix.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230623081250.h20rlLik@linutronix.de> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 3AB7E160024 X-Stat-Signature: i4ty9p7u6tzj8weghqpfp87bumwfjyh7 X-Rspam-User: X-HE-Tag: 1687516827-958717 X-HE-Meta: U2FsdGVkX1/J1bbt6eH8mK8AXrzr/OqMIVx9LpTcNGlM/1bdfqgWJDLbz1JZlGXCNzuYpLMQWc02eEnZo8j7KsjxoftSbdaGW58pvbl/XKDGas0gD45CahB7UYh4bgJAJTB8MjbAxUvpLL5RslDWxhLxaFE9209QKbeUjOyVXUhc6/VmY96BEFtmpQVebqQrYBKJl0jlR0nmiooYh82gpjcN+NGuGVlgrm68Mnr+tm4Xd11+wbiSgtk58eo7z/pTF4GH8FiD4OY9Oh8g/Oc8Gd3HHDcKieK4Y5jh3NDYzR8EgcM4PLPnjQEO4UiaR5Zdy3IX2ht4fJ/7m1tb1WUnFMkeVSComGQxMkA+RAccFa0j/NVEYJ3Nc3fG/QWOPwHSs5v8EPDZ2+B6rnO4NKYrZphVery27nshjODIXAGaEA8FnDVRtxuOyxJfwfgE/KODoDLIOCORIBQvtElvNn7qvwAE7ya2OPxxhONSH9JihSmuRTKD6r32ariFPjLnBnFjs7LQPUVgb8LQ+y8iOiB9ngm5V1S+wK7i97zKtv05WqnUDK5cEcx3nUH2R4t/W09PePz+mb4u21QvPi7IujUlHFlGgAEVaLNxVXV5chgzn6pR9OLpnL36+jsCciP980Yqo2HZPOFJ6Je5xN057ur1vLEeUeIBMHKbKcuf/+FJR3xAXgUWu2MGTRj+sgsBYej9m77MZ7MCcuBTtiyI5WjcJajrZAfCDg/+y3wHtn9KFUBkTUInYoiTl++C98fGGPXzVpJbI6ioA8ckby7krQUvTihok3su90WStFdjP6gglcyes+dSyXBUqfyDLk+TzCgvLbdjSkFZtS7RCiuxE4loOZWnk9zwg5Np0XabN10BEHeHrXJBQZs6PazojDnoKlngydLu6pxmqNQV4GtcqaG6vCCyIPfpCHi8bc1Sl6sPu/VeNXaVuRfvLFIfgk/cq8ZDj6lbviqVoweiqvjk3Pb b2oMzwT7 tBfWdiaqDgZ9dzz8x6aYf4000wZY10RzfO6pSkOYsdkgEe/jXj/uYdLt1VNX/RUH+HtBk1FZnxTxQEG6Txg4k90lYmJSuX/4xjoRS0izhlmTBjnnZaXnyCMG2o8Kmaq40CB8V5luDOvpdcrRxtxMIxT9N/QzhK4v8JotO+AKh9veQjt+j/HCRSIMBhIVnStvPY7FY 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 2023-06-23 10:12:50, Sebastian Andrzej Siewior wrote: > On 2023-06-21 17:38:03 [+0200], Petr Mladek wrote: > > But wait. AFAIK, the printk kthread is implemented only for the serial > > console. So, it won't be safe for other consoles, especially > > the problematic tty_insert_flip_string_and_push_buffer() call. > > > OK, what about using migrate_disable() in printk_deferred_enter()? > > Something like: > > > > /* > > * The printk_deferred_enter/exit macros are available only as a hack. > > * They define a per-CPU context where all printk console printing > > * is deferred because it might cause a deadlock otherwise. > > * > > * It is highly recommended to use them only in a context with interrupts > > * disabled. Otherwise, other unrelated printk() calls might be deferred > > * when they interrupt/preempt the deferred code section. > > * > > * They should not be used for to deffer printing of many messages. It might > > * create softlockup when they are flushed later. > > * > > * IMPORTANT: Any new use of these MUST be consulted with printk maintainers. > > * It might have unexpected side effects on the printk infrastructure. > > */ > > #ifdef CONFIG_PREEMPT_RT > > > > #define printk_deferred_enter() \ > > do { \ > > migrate_disable(); \ > > __printk_safe_enter(); \ > > } while (0) > > > > #define printk_deferred_exit() \ > > do { \ > > __printk_safe_exit(); \ > > migrate_enable(); \ > > } while (0) > > > > #else /* CONFIG_PREEMPT_RT */ > > > > #define printk_deferred_enter() \ > > do { \ > > preempt_disable(); \ > > __printk_safe_enter(); \ > > } while (0) > > > > #define printk_deferred_exit() \ > > do { \ > > __printk_safe_exit(); \ > > preempt_enable(); \ > > } while (0) > > > > #endif /* CONFIG_PREEMPT_RT */ > > > > Note that I have used preempt_disable() on non-RT because it is much > > cheaper. And IRQs will be disabled anyway on non-RT system > > in this code path. > > It would do _but_ is it really needed? All users but one (the one in > __build_all_zonelists()) have interrupts already disabled. This isn't a > hot path and is not used very common. Does it justify the ifdef? > > An unconditional migrate_disable() would do the job if you want it to be > safe Makes sense. The ifdef does not look worth it. > but I would rather suggest lockdep annotation instead of disabling > either preemption or migration. If I read the comment on top right, this > API isn't open for the public. It might work when mm people agree to explicitly call migrate_disable() in __build_all_zonelists(). I mean to call there: migrate_disable(); printk_deferred_enter(); write_seqlock_irqsave(&zonelist_update_seq, flags); Plus it would require some comments. For me, it is acceptable to hide at least the migrate_disable() part into printk_deferred_enter(). > The global variable would be probably be simpler but I guess you want > to have direct printing on other CPUs. Yes, the scope should be as limited as possible. > To be honst, I would suggest to work towards always printing in a thread > with an emergency console than this deferred/ safe duckt tape. I have used this argument many years. But it is not much convincing after 10 years. Note that John has sent 1st RFC 4 years ago and we still do not have the kthreads :-/ Best Regards, Petr