On Wed, 14 May 2014, Peter Zijlstra wrote:
> On Wed, May 14, 2014 at 03:51:19PM +0200, Frederic Weisbecker wrote:
> > > Anyway, if it turns out to really be needed, the split list doesn't
> > > sound bad.
> >
> > Either that or we can remove LAZY stuff and wait to see if people complain
> > :)
>
On Wed, May 14, 2014 at 03:51:19PM +0200, Frederic Weisbecker wrote:
> > Anyway, if it turns out to really be needed, the split list doesn't
> > sound bad.
>
> Either that or we can remove LAZY stuff and wait to see if people complain :)
How big do we need tested? I'm fairly sure RHT has some med
On Wed, May 14, 2014 at 02:41:50PM +0200, Peter Zijlstra wrote:
> On Wed, May 14, 2014 at 02:11:25PM +0200, Frederic Weisbecker wrote:
> > > I don't think it is, most apic calls do apic_wait_icr_idle() then the
> > > apic op, if an NMI happens in between and writes to the APIC, the return
> > > con
On Wed, May 14, 2014 at 02:11:25PM +0200, Frederic Weisbecker wrote:
> > I don't think it is, most apic calls do apic_wait_icr_idle() then the
> > apic op, if an NMI happens in between and writes to the APIC, the return
> > context will see a !idle icr and fail.
> >
> > This is why arch_irq_work_r
On Wed, May 14, 2014 at 01:54:06PM +0200, Peter Zijlstra wrote:
> On Wed, May 14, 2014 at 01:38:14PM +0200, Frederic Weisbecker wrote:
> > > > +bool irq_work_queue_on(struct irq_work *work, int cpu)
> > > > +{
> > > > + /* Only queue if not already pending */
> > > > + if (!irq_work_cla
On Wed, May 14, 2014 at 01:38:14PM +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 f
On Wed, May 14, 2014 at 11:06:29AM +0200, Peter Zijlstra wrote:
> On Wed, May 14, 2014 at 12:25:54AM +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 Wed, May 14, 2014 at 11:06:29AM +0200, Peter Zijlstra wrote:
> > + llist_add(&work->llnode, &per_cpu(irq_work_list, cpu));
> > + native_send_call_func_single_ipi(cpu);
>
> At the very leastestest make that:
>
> if (llist_add(&work->llnode, &per_cpu(irq_work_list, cpu)))
>
On Wed, May 14, 2014 at 12:25:54AM +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
10 matches
Mail list logo
