public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Greg KH <gregkh@linuxfoundation.org>,
	Prasad Sodagudi <psodagud@codeaurora.org>
Cc: rostedt@goodmis.org, pmladek@suse.com,
	sergey.senozhatsky@gmail.com, linux-kernel@vger.kernel.org,
	tkjos@google.com, Mohammed Khajapasha <mkhaja@codeaurora.org>
Subject: Re: [PATCH 2/2] printk: Make the console flush configurable in hotplug path
Date: Thu, 24 Sep 2020 20:21:07 +0200	[thread overview]
Message-ID: <87wo0j6nos.fsf@nanos.tec.linutronix.de> (raw)
In-Reply-To: <20200924063352.GB592892@kroah.com>

On Thu, Sep 24 2020 at 08:33, Greg KH wrote:
> On Wed, Sep 23, 2020 at 05:08:32PM -0700, Prasad Sodagudi wrote:
>> +config CONSOLE_FLUSH_ON_HOTPLUG
>> +	bool "Enable console flush configurable in hot plug code path"
>> +	depends on HOTPLUG_CPU
>> +	def_bool n
>
> n is the default, no need to list it.
>
>> +	help
>> +	In cpu hot plug path console lock acquire and release causes the
>> +	console to flush. If console lock is not free hot plug latency
>> +	increases. So make console flush configurable in hot plug path
>> +	and default disabled to help in cpu hot plug latencies.
>
> Why would you not want this option?
>
> Why isn't this just a bugfix?

Because it's the normal behaviour of console lock and there are
gazillion other ways to delay stuff in the hotplug path.

CPU hotplug is not meant to be a high speed operation and if people
think they need it to be fast then its pretty much guaranteed that they
want it for the completely wrong reasons.

This #ifdef tinkering is just digusting especially as it just tackles an
obvious way how to delay timer migration, but does not address the
underlying root cause.

>> +#ifdef CONFIG_CONSOLE_FLUSH_ON_HOTPLUG
>
> #ifdef in .c code is a mess to maintain.
>
>>  	ret = cpuhp_setup_state_nocalls(CPUHP_PRINTK_DEAD, "printk:dead", NULL,
>>  					console_cpu_notify);
>>  	WARN_ON(ret < 0);
>>  	ret = cpuhp_setup_state_nocalls(CPUHP_AP_ONLINE_DYN, "printk:online",
>>  					console_cpu_notify, NULL);
>>  	WARN_ON(ret < 0);
>> -	return 0;
>> +#endif
>
> What happens if we don't make these calls entirely?  Why not just remove
> them as who wants extra latency for their system?

That's just wrong. If you don't want output, then adjust your loglevel,
but delaying printks up to the point where by chance another printk
happens is just silly.

CPU hotplug is not about latency. It's slow by design and again, the
timer migration is simply happening at the wrong place. But fixing that
needs more thoughts than modifying log levels and sprinkling a few
#ifdefs into the code.

Thanks,

        tglx

  reply	other threads:[~2020-09-24 18:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-24  0:08 [PATCH 1/2] genirq/cpuhotplug: Reduce logging level for couple of prints Prasad Sodagudi
2020-09-24  0:08 ` [PATCH 2/2] printk: Make the console flush configurable in hotplug path Prasad Sodagudi
2020-09-24  6:33   ` Greg KH
2020-09-24 18:21     ` Thomas Gleixner [this message]
2020-09-25  9:27       ` Greg KH
2020-09-25 14:16         ` Adam Borowski
2020-09-25 22:55           ` Thomas Gleixner
2020-09-28  2:05       ` psodagud
2020-09-28 12:50         ` Greg KH
2020-09-30 14:36         ` Petr Mladek
2020-09-24  6:38   ` Sergey Senozhatsky
2020-09-30 13:57   ` Petr Mladek
2020-09-24  6:31 ` [PATCH 1/2] genirq/cpuhotplug: Reduce logging level for couple of prints Greg KH
2020-09-24 18:08 ` Thomas Gleixner

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=87wo0j6nos.fsf@nanos.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkhaja@codeaurora.org \
    --cc=pmladek@suse.com \
    --cc=psodagud@codeaurora.org \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tkjos@google.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