Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp99549pxj; Fri, 7 May 2021 04:45:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy3qfGBfX2jmCp4IAhw7tUEWzRFZpX3dSk/jyjc7d3ZtvflPIV4/KNT3OoxNvZbffR2JCcN X-Received: by 2002:a05:6402:1583:: with SMTP id c3mr3549185edv.211.1620387946285; Fri, 07 May 2021 04:45:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620387946; cv=none; d=google.com; s=arc-20160816; b=zTGVqyH/BIl0F9IINV177Xi2gvsLcbnUdRKghzNpe+Zi5ir/GvuA7Kuh1R6EKSdMcd RdeWA56eg1GYcAcxO26+LpJO45usUIKNsddX//Je8XwtYhGzflaJxoDzOTCBMzXs+Zzt AtXCMBNrHIB4BZB6+GxU5bq78MWPtGi8skppL/OJNfAGl6DnK/3T4Dk55p7RRZ29FSH8 QCWvIentWmOUjz3dSYYY1D8Ktei8itgDvGeLQtgI4uyM8ABo/Na61VM+SLe93nalSKlN xBJi0O5un9TPRQU+ryF9S8He3est0BjUjyDPdtrrbUGgzIITS1txx0VJKmXSiu977e0N 7pmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-language:content-transfer-encoding :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=ESJ1BwZtwcZc3TYqwIdy826kEG1EJ5CZHKTBYOaNYCI=; b=THZerq4wLuCcm5bjJu4DzCFbQAKzd5uFvrHwwUCpAMnRWHhvMLOVinJhGGksETmWxi h27O8vG6PyEx2hLZQzK17KcH+RFXs1yypzoiVqClhJ746sUexjwMkufRirQY2LMlGwQn TQB0eAD/HLa/GZe6st2chOtml0wEzScvt/2nV+Nvu/IUlfz5vjl9QcK55VBOCZT/LrLx zaFjfn6NjSls069W3TmvqWD/9LTe7uehJIgoGxmC3ZLbH7wKZYQSftdrKxx80cwGZX+X ry8zl4xHW+AQyG3rif6X2SI7BJcLCXtQvFPI6EwLg8o1ZlyO0e6X4qAx48pjQLy2edMn lvZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j23si5644084eje.99.2021.05.07.04.45.21; Fri, 07 May 2021 04:45:46 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236351AbhEGIhB (ORCPT + 99 others); Fri, 7 May 2021 04:37:01 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:17143 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236337AbhEGIhA (ORCPT ); Fri, 7 May 2021 04:37:00 -0400 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Fc3bs1dMPzqT3C; Fri, 7 May 2021 16:32:41 +0800 (CST) Received: from [127.0.0.1] (10.40.192.131) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.498.0; Fri, 7 May 2021 16:35:49 +0800 Subject: Re: [PATCH] printk: stop spining waiter when console resume to flush prb To: Steven Rostedt CC: , , , , , References: <1620288026-5373-1-git-send-email-luojiaxing@huawei.com> <20210506091323.20ba2464@gandalf.local.home> From: luojiaxing Message-ID: Date: Fri, 7 May 2021 16:35:49 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20210506091323.20ba2464@gandalf.local.home> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.40.192.131] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021/5/6 21:13, Steven Rostedt wrote: > On Thu, 6 May 2021 16:00:26 +0800 > Luo Jiaxing wrote: > >> Some threads still call printk() for printing when resume_console() is >> being executed. In practice, the printk() is executed for a period of time >> and then returned. The duration is determined by the number of prints >> cached in the prb during the suspend/resume process. At the same time, >> resume_console() returns quickly. >> >> Base on owner/waiter machanism, the frist one who fail to lock console will >> become waiter, and start spining. When current owner finish print one >> informance, if a waiter is waitting, owner will give up and let waiter >> become a new owner. New owner need to flush the whole prb unitl prb empty >> or another new waiter come and take the job from him. >> >> So the first waiter after resume_console() will take seconds to help to >> flush prb, but driver which call printk() may be bothered by this. New >> a flag to mark resume flushing prb. When the console resume, before the >> prb is empty, stop to set a new waiter temporarily. >> >> Signed-off-by: Luo Jiaxing >> --- >> kernel/printk/printk.c | 9 ++++++++- >> 1 file changed, 8 insertions(+), 1 deletion(-) >> >> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c >> index 575a34b..2c680a5 100644 >> --- a/kernel/printk/printk.c >> +++ b/kernel/printk/printk.c >> @@ -287,6 +287,9 @@ EXPORT_SYMBOL(console_set_on_cmdline); >> /* Flag: console code may call schedule() */ >> static int console_may_schedule; >> >> +/* Flags: console flushing prb when resume */ >> +static atomic_t console_resume_flush_prb = ATOMIC_INIT(0); > Why are you using an atomic? It's accessed within locks. Hi, Steven, My method is to add a flag. When the flag is set, the console_resume context can exclusively keep the sonsole ower lock. As for each CPU may invoke printk at any time, we have to ensure that each CPU can obtain the latest flag value in a timely manner. Initially, wmb was also considered, but I think wmb is not suitable for machines with multiple NUMA nodes, atomic variables were used then. In addition, only console_resume sets the flag, so whether the flag is locked is not considered. Thanks Jiaxing > > static bool console_resuming; > > >> + >> enum con_msg_format_flags { >> MSG_FORMAT_DEFAULT = 0, >> MSG_FORMAT_SYSLOG = (1 << 0), >> @@ -1781,7 +1784,8 @@ static int console_trylock_spinning(void) >> raw_spin_lock(&console_owner_lock); >> owner = READ_ONCE(console_owner); >> waiter = READ_ONCE(console_waiter); > resuming = READ_ONCE(console_removing); > >> - if (!waiter && owner && owner != current) { > if (!resuming && (!waiter ... > >> + if (!waiter && owner && owner != current && >> + !atomic_read(&console_resume_flush_prb)) { >> WRITE_ONCE(console_waiter, true); >> spin = true; >> } >> @@ -2355,6 +2359,7 @@ void resume_console(void) >> if (!console_suspend_enabled) >> return; >> down_console_sem(); >> + atomic_set(&console_resume_flush_prb, 1); >> console_suspended = 0; > resuming = true; > >> console_unlock(); > /* Keep clearing resume from entering the console_unlock */ > smp_wmb(); > resuming = false; > > >> } >> @@ -2592,6 +2597,8 @@ void console_unlock(void) >> raw_spin_unlock(&logbuf_lock); >> >> up_console_sem(); >> + if (atomic_read(&console_resume_flush_prb)) >> + atomic_set(&console_resume_flush_prb, 0); > Get rid of the above. > > -- Steve > >> >> /* >> * Someone could have filled up the buffer again, so re-check if there's > > . >