On Tue, Jun 03, 2014 at 01:02:39PM -0700, Eric Dumazet wrote:
> On Tue, 2014-06-03 at 18:37 +0200, Peter Zijlstra wrote:
> > On Tue, Jun 03, 2014 at 09:29:07AM -0700, Eric Dumazet wrote:
> > > > +bool irq_work_queue_on(struct irq_work *work, int cpu)
> > > > +{
> > > > + /* All work should ha
On Tue, 2014-06-03 at 18:37 +0200, Peter Zijlstra wrote:
> On Tue, Jun 03, 2014 at 09:29:07AM -0700, Eric Dumazet wrote:
> > > +bool irq_work_queue_on(struct irq_work *work, int cpu)
> > > +{
> > > + /* All work should have been flushed before going offline */
> > > + WARN_ON_ONCE(cpu_is_offline(cp
On Tue, Jun 03, 2014 at 09:29:07AM -0700, Eric Dumazet wrote:
> > +bool irq_work_queue_on(struct irq_work *work, int cpu)
> > +{
> > + /* All work should have been flushed before going offline */
> > + WARN_ON_ONCE(cpu_is_offline(cpu));
> > +
> > + /* Arch remote IPI send/receive backend aren
On Tue, 2014-06-03 at 16:40 +0200, Frederic Weisbecker wrote:
> irq work currently only supports local callbacks. However its code
> is mostly ready to run remote callbacks and we have some potential user.
>
> The full nohz subsystem currently open codes its own remote irq work
> on top of the sch
On Tue, Jun 03, 2014 at 05:00:08PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 03, 2014 at 04:40:18PM +0200, Frederic Weisbecker wrote:
> > irq work currently only supports local callbacks. However its code
> > is mostly ready to run remote callbacks and we have some potential user.
> >
> > The ful
On Tue, Jun 03, 2014 at 04:40:18PM +0200, Frederic Weisbecker wrote:
> irq work currently only supports local callbacks. However its code
> is mostly ready to run remote callbacks and we have some potential user.
>
> The full nohz subsystem currently open codes its own remote irq work
> on top of
irq work currently only supports local callbacks. However its code
is mostly ready to run remote callbacks and we have some potential user.
The full nohz subsystem currently open codes its own remote irq work
on top of the scheduler ipi when it wants a CPU to reevaluate its next
tick. However this
On Mon, May 26, 2014 at 09:19:18PM +0200, Peter Zijlstra wrote:
> On Mon, May 26, 2014 at 06:50:41PM +0200, Frederic Weisbecker wrote:
> > On Mon, May 26, 2014 at 06:02:24PM +0200, Peter Zijlstra wrote:
> > > On Sun, May 25, 2014 at 04:29:49PM +0200, Frederic Weisbecker wrote:
> > > > +bool irq_wor
On Mon, May 26, 2014 at 06:50:41PM +0200, Frederic Weisbecker wrote:
> On Mon, May 26, 2014 at 06:02:24PM +0200, Peter Zijlstra wrote:
> > On Sun, May 25, 2014 at 04:29:49PM +0200, Frederic Weisbecker wrote:
> > > +bool irq_work_queue_on(struct irq_work *work, int cpu)
> > > +{
> > > + /* Only queu
On Mon, May 26, 2014 at 06:02:24PM +0200, Peter Zijlstra wrote:
> On Sun, May 25, 2014 at 04:29:49PM +0200, Frederic Weisbecker wrote:
> > +bool irq_work_queue_on(struct irq_work *work, int cpu)
> > +{
> > + /* Only queue if not already pending */
> > + if (!irq_work_claim(work))
> > +
On Sun, May 25, 2014 at 04:29:49PM +0200, Frederic Weisbecker wrote:
> +bool irq_work_queue_on(struct irq_work *work, int cpu)
> +{
> + /* Only queue if not already pending */
> + if (!irq_work_claim(work))
> + return false;
> +
> + /* All work should have been flushed befor
irq work currently only supports local callbacks. However its code
is mostly ready to run remote callbacks and we have some potential user.
The full nohz subsystem currently open codes its own remote irq work
on top of the scheduler ipi when it wants a CPU to reevaluate its next
tick. However this
12 matches
Mail list logo
