linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: luojiaxing <luojiaxing@huawei.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: <pmladek@suse.com>, <sergey.senozhatsky@gmail.com>,
	<john.ogness@linutronix.de>, <linux-kernel@vger.kernel.org>,
	<linuxarm@huawei.com>, <bobo.shaobowang@huawei.com>
Subject: Re: [PATCH] printk: stop spining waiter when console resume to flush prb
Date: Fri, 7 May 2021 16:35:49 +0800	[thread overview]
Message-ID: <a623b823-9497-db9d-9d81-6b8cbb0931d3@huawei.com> (raw)
In-Reply-To: <20210506091323.20ba2464@gandalf.local.home>


On 2021/5/6 21:13, Steven Rostedt wrote:
> On Thu, 6 May 2021 16:00:26 +0800
> Luo Jiaxing <luojiaxing@huawei.com> 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 <luojiaxing@huawei.com>
>> ---
>>   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
>
> .
>


  reply	other threads:[~2021-05-07  8:36 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-06  8:00 [PATCH] printk: stop spining waiter when console resume to flush prb Luo Jiaxing
2021-05-06 13:13 ` Steven Rostedt
2021-05-07  8:35   ` luojiaxing [this message]
2021-05-06 13:39 ` Petr Mladek
2021-05-06 14:07   ` Sergey Senozhatsky
2021-05-06 14:12     ` Sergey Senozhatsky
2021-05-06 15:14       ` John Ogness
2021-05-07  7:58         ` luojiaxing
2021-05-07  7:33       ` luojiaxing
2021-05-07  7:49         ` Sergey Senozhatsky
2021-05-07 16:36       ` Petr Mladek
2021-05-10  8:26         ` Sergey Senozhatsky
2021-05-10 10:17           ` Petr Mladek
2021-05-10 10:32             ` John Ogness
2021-05-10 11:16               ` Sergey Senozhatsky
2021-05-10 11:43             ` Sergey Senozhatsky
2021-05-07 16:13     ` Petr Mladek
2021-05-10  8:29       ` luojiaxing
2021-05-10  9:50         ` Petr Mladek
2021-05-10 12:06           ` Sergey Senozhatsky
2021-05-10  7:41   ` luojiaxing
2021-05-10  9:30     ` Petr Mladek
2021-05-11  7:32       ` luojiaxing
2021-05-11  9:08         ` Petr Mladek
2021-05-13  7:55           ` luojiaxing

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a623b823-9497-db9d-9d81-6b8cbb0931d3@huawei.com \
    --to=luojiaxing@huawei.com \
    --cc=bobo.shaobowang@huawei.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=pmladek@suse.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).