From: Petr Mladek <pmladek@suse.com>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: 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: Tue, 19 Jan 2016 17:16:57 +0100 [thread overview]
Message-ID: <20160119161656.GC2148@dhcp128.suse.cz> (raw)
In-Reply-To: <20160119150040.GA558@swordfish>
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.
> console_unlock() /* w/o can_use_console() in logbuf_lock section */
> ....
> again:
> for (;;) {
> raw_spin_lock_irqsave logbuf_lock
> msg_print_text
> raw_spin_unlock logbuf_lock
> call_console_drivers
> local_irq_restore
> }
>
> up_console_sem
>
> raw_spin_lock logbuf_lock
> retry = console_seq != log_next_seq
> raw_spin_unlock_irqrestore logbuf_lock
>
> if retry && console_trylock()
> goto again;
>
>
> 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;
Then we remove this check from console_trylock_for_printk() and
eventually remove this function altogether.
It means that the code will be easier and protected against the
theoretical race.
How does that sound, please?
Best Regards,
Petr
next prev parent reply other threads:[~2016-01-19 16:17 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 [this message]
2016-01-20 4:18 ` Sergey Senozhatsky
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=20160119161656.GC2148@dhcp128.suse.cz \
--to=pmladek@suse.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=sergey.senozhatsky.work@gmail.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
all inboxes | Powered by JetHome®