From: Jan Kara <jack@suse.cz>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@suse.cz>,
Steven Rostedt <rostedt@goodmis.org>
Subject: Re: [PATCH 2/4] irq_work: Provide a irq work that can be processed on any cpu
Date: Thu, 7 Nov 2013 23:50:34 +0100 [thread overview]
Message-ID: <20131107225034.GD2054@quack.suse.cz> (raw)
In-Reply-To: <20131107222311.GA28130@localhost.localdomain>
On Thu 07-11-13 23:23:14, Frederic Weisbecker wrote:
> On Thu, Nov 07, 2013 at 11:19:04PM +0100, Jan Kara wrote:
> > On Thu 07-11-13 23:13:39, Frederic Weisbecker wrote:
> > > But then, who's going to process that work if every CPUs is idle?
> > Have a look into irq_work_queue(). There is:
> > /*
> > * If the work is not "lazy" or the tick is stopped, raise the irq
> > * work interrupt (if supported by the arch), otherwise, just wait
> > * for the next tick. We do this even for unbound work to make sure
> > * *some* CPU will be doing the work.
> > */
> > if (!(work->flags & IRQ_WORK_LAZY) || tick_nohz_tick_stopped()) {
> > if (!this_cpu_cmpxchg(irq_work_raised, 0, 1))
> > arch_irq_work_raise();
> > }
> >
> > So we raise an interrupt if there would be no timer ticking (which is
> > what I suppose you mean by "CPU is idle"). That is nothing changed by my
> > patches...
>
> Ok but we raise that interrupt locally, not to the other CPUs.
True, but that doesn't really matter in this case. Any CPU (including the
local one) can handle the unbound work. So from the definition of the
unbound work things are OK.
Regarding my use for printk - if all (other) CPUs are idle then we can
easily afford making the current cpu busy printing, that's not a problem.
There's nothing else to do than to print what's remaining in the printk
buffer...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
next prev parent reply other threads:[~2013-11-07 22:50 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-07 21:48 [PATCH 0/4 v6] Avoid softlockups in console_unlock() Jan Kara
2013-11-07 21:48 ` [PATCH 1/4] printk: Remove separate printk_sched buffers and use printk buf instead Jan Kara
2013-11-07 21:48 ` [PATCH 2/4] irq_work: Provide a irq work that can be processed on any cpu Jan Kara
2013-11-07 22:13 ` Frederic Weisbecker
2013-11-07 22:19 ` Jan Kara
2013-11-07 22:23 ` Frederic Weisbecker
2013-11-07 22:50 ` Jan Kara [this message]
2013-11-07 22:54 ` Frederic Weisbecker
2013-11-07 23:01 ` Jan Kara
2013-11-07 23:31 ` Steven Rostedt
2013-11-08 10:18 ` Jan Kara
2013-11-07 22:32 ` Frederic Weisbecker
2013-11-07 21:48 ` [PATCH 3/4] printk: Defer printing to irq work when we printed too much Jan Kara
2013-11-07 22:43 ` Frederic Weisbecker
2013-11-07 22:57 ` Jan Kara
2013-11-07 23:21 ` Frederic Weisbecker
2013-11-07 23:37 ` Steven Rostedt
2013-11-07 23:44 ` Frederic Weisbecker
2013-11-07 23:46 ` Frederic Weisbecker
2013-11-08 10:21 ` Jan Kara
2013-11-22 23:27 ` Andrew Morton
2013-11-25 12:08 ` Jan Kara
2013-11-11 21:54 ` Pavel Machek
2013-11-11 22:17 ` Jan Kara
2013-11-16 11:35 ` Pavel Machek
2013-11-07 22:59 ` Steven Rostedt
2013-11-07 21:48 ` [PATCH 4/4] printk: Use unbound irq work for printing and waking Jan Kara
-- strict thread matches above, loose matches on Subject: below --
2013-08-21 8:08 [PATCH 0/4 v6] Avoid softlockups in console_unlock() Jan Kara
2013-08-21 8:08 ` [PATCH 2/4] irq_work: Provide a irq work that can be processed on any cpu Jan Kara
2013-08-21 18:49 ` Steven Rostedt
2013-09-05 15:56 ` Jan Kara
2013-08-14 13:28 [PATCH 0/4 v5] Avoid softlockups in console_unlock() Jan Kara
2013-08-14 13:28 ` [PATCH 2/4] irq_work: Provide a irq work that can be processed on any cpu Jan Kara
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=20131107225034.GD2054@quack.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.cz \
--cc=rostedt@goodmis.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;
as well as URLs for NNTP newsgroup(s).