From: Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Tejun Heo <tj@kernel.org>, Jan Kara <jack@suse.com>,
Kyle McMartin <kyle@kernel.org>,
Dave Jones <davej@codemonkey.org.uk>,
Calvin Owens <calvinowens@fb.com>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH -next 1/2] printk: move can_use_console out of console_trylock_for_printk
Date: Wed, 20 Jan 2016 13:18:04 +0900 [thread overview]
Message-ID: <20160120041804.GB506@swordfish> (raw)
In-Reply-To: <20160119161656.GC2148@dhcp128.suse.cz>
On (01/19/16 17:16), Petr Mladek wrote:
> On Wed 2016-01-20 00:00:40, Sergey Senozhatsky wrote:
> > > But do we really need to repeat the check in every cycle?
> >
> > well, on every iteration in the best case we check cpu_online()
> > only. which is what we would have done anyway in vprintk_emit(),
> > so no additional checks added. at the same time call_console_drivers
> > does not do '!cpu_online && !CON_ANYTIME' for each console now, so
> > in some sense there are less checks now (this is far even from a
> > micro-optimization, just noted).
>
> Hmm, we need to keep the check in call_console_drivers(). It iterates
> over all registered consoles. Only some of them could habe CON_ANYTIME
> flag. We need to skip the others when the CPU is not online.
oh... good point, you are right! my bad. so we basically need both. the
first one (can_use_console() before call_console_drivers()) ensures that
it's _generally_ OK to call call_console_drivers() later and that it will
not drain messages, the second one _in_ call_console_drivers() filters out
only CON_ANYTIME consoles if !cpu_online(), but by this time we are sure
that there is at least one CON_ANYTIME console.
[..]
> > when we up_console_sem(), consoles may appear and disappear, since we
> > don't keep the semaphore. Suppose that we have OFFLINE cpu and we had a
> > CON_ANYTIME console, but in between up_console_sem--console_trylock
> > that single CON_ANYTIME console was removed. So now we have !cpu_online
> > and !CON_ANYTIME.
>
> Ah, I have missed that the console_sem is released/taken before goto
> again. Hmm, your proposed solution adds even more twists into the code.
> I think how to make it easier. I think that we could move the again:
> target and call console_cont_flush() when there is some new content.
> It is a corner case, anyway. Then we could do:
>
>
> do_cond_resched = console_may_schedule;
> console_may_schedule = 0;
>
> +again:
> + if (!can_use_console()) {
> + console_locked = 0;
> + up_console_sem();
> + return;
> }
>
> /* flush buffered message fragment immediately to console */
> console_cont_flush(text, sizeof(text));
> -again:
> for (;;) {
> struct printk_log *msg;
>
looks better. we do extra IRQ disable/enable (spin lock irq) when we jump
to `again' label, but I don't think this introduces any significant overhead.
however, if it does, we always can avoid extra console_cont_flush() by simply
checking @retry -- it's `false' only once, when we execute this part for
the first time in the current console_unlock() call; all goto-jumps imply
that @retry is `true'.
IOW:
bool retry = false;
again:
can_use_console
if (!retry) /* if we jumped to again, retry is true */
console_cont_flush
for (;;) {
...
}
retry = ...
if retry && console_trylock()
goto retry;
> Then we remove this check from console_trylock_for_printk() and
> eventually remove this function altogether.
yes, that was the plan :)
> It means that the code will be easier and protected against the
> theoretical race.
>
> How does that sound, please?
sounds good, thanks.
> Best Regards,
> Petr
-ss
next prev parent reply other threads:[~2016-01-20 4:16 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-14 4:57 [RFC][PATCH -next 0/2] cond_resched() some of console_trylock callers Sergey Senozhatsky
2016-01-14 4:57 ` [RFC][PATCH -next 1/2] printk: move can_use_console out of console_trylock_for_printk Sergey Senozhatsky
2016-01-14 5:59 ` [PATCH " Sergey Senozhatsky
2016-01-18 15:42 ` [RFC][PATCH -next " Petr Mladek
2016-01-19 0:42 ` Sergey Senozhatsky
2016-01-19 13:31 ` Petr Mladek
2016-01-19 15:00 ` Sergey Senozhatsky
2016-01-19 16:16 ` Petr Mladek
2016-01-20 4:18 ` Sergey Senozhatsky [this message]
2016-01-20 10:09 ` Petr Mladek
2016-01-14 4:57 ` [RFC][PATCH -next 2/2] printk: set may_schedule for some of console_trylock callers Sergey Senozhatsky
2016-01-17 14:11 ` Sergey Senozhatsky
2016-01-17 14:23 ` Sergey Senozhatsky
2016-01-18 16:17 ` Petr Mladek
2016-01-19 1:15 ` Sergey Senozhatsky
2016-01-19 15:18 ` Petr Mladek
2016-01-20 3:50 ` Sergey Senozhatsky
2016-01-20 11:51 ` Sergey Senozhatsky
2016-01-20 12:38 ` Petr Mladek
2016-01-20 12:31 ` Petr Mladek
2016-01-21 1:25 ` Sergey Senozhatsky
2016-01-21 5:51 ` Sergey Senozhatsky
2016-01-22 9:48 ` Petr Mladek
2016-01-23 4:46 ` Sergey Senozhatsky
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=20160120041804.GB506@swordfish \
--to=sergey.senozhatsky.work@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=calvinowens@fb.com \
--cc=davej@codemonkey.org.uk \
--cc=jack@suse.com \
--cc=kyle@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pmladek@suse.com \
--cc=sergey.senozhatsky@gmail.com \
--cc=tj@kernel.org \
/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