Re: [PATCH 2/4] irq_work: Provide a irq work that can be processedon any cpu

[Jan Kara]

On Thu 07-11-13 23:54:10, Frederic Weisbecker wrote:
> On Thu, Nov 07, 2013 at 11:50:34PM +0100, Jan Kara wrote:
> > 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.
> 
> I don't see how that can be ok. You want to offline a work because the
> local CPU can't handle it, right? If the local CPU can handle it you can
> just use local irq works.
> 
> > 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...
> 
> So if the current CPU can handle it, what is the problem?
  I hope this gets cleared out in my other email. But to make sure: If
other CPUs are idle (i.e. not appending to the printk buffer), we can well
handle the printing on the current CPU (with some breaks to allow
interrupts to be served etc.). If other CPUs are also appending to printk
buffer, that's where we really want to push the work to other CPUs.

								Honza
-- 
Jan Kara <jack@xxxxxxx>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/