From: Frederic Weisbecker <fweisbec@gmail.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Ingo Molnar <mingo@kernel.org>, Kevin Hilman <khilman@linaro.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Viresh Kumar <viresh.kumar@linaro.org>
Subject: Re: [PATCH 1/5] irq_work: Split raised and lazy lists
Date: Mon, 26 May 2014 21:33:50 +0200 [thread overview]
Message-ID: <20140526193347.GJ2066@localhost.localdomain> (raw)
In-Reply-To: <20140526192633.GB5444@laptop.programming.kicks-ass.net>
On Mon, May 26, 2014 at 09:26:33PM +0200, Peter Zijlstra wrote:
> On Mon, May 26, 2014 at 06:53:13PM +0200, Frederic Weisbecker wrote:
> > On Mon, May 26, 2014 at 05:59:44PM +0200, Peter Zijlstra wrote:
> > > On Sun, May 25, 2014 at 04:29:47PM +0200, Frederic Weisbecker wrote:
> > > > An irq work can be handled from two places: from the tick if the work
> > > > carries the "lazy" flag and the tick is periodic, or from a self IPI.
> > > >
> > > > We merge all these works in a single list and we use some per cpu latch
> > > > to avoid raising a self-IPI when one is already pending.
> > > >
> > > > Now we could do away with this ugly latch if only the list was only made of
> > > > non-lazy works. Just enqueueing a work on the empty list would be enough
> > > > to know if we need to raise an IPI or not.
> > > >
> > > > Also we are going to implement remote irq work queuing. Then the per CPU
> > > > latch will need to become atomic in the global scope. That's too bad
> > > > because, here as well, just enqueueing a work on an empty list of
> > > > non-lazy works would be enough to know if we need to raise an IPI or not.
> > > >
> > > > So lets take a way out of this: split the works in two distinct lists,
> > > > one for the works that can be handled by the next tick and another
> > > > one for those handled by the IPI. Just checking if the latter is empty
> > > > when we queue a new work is enough to know if we need to raise an IPI.
> > >
> > > That ^
> > >
> > > > bool irq_work_queue(struct irq_work *work)
> > > > {
> > > > + unsigned long flags;
> > > > +
> > > > /* Only queue if not already pending */
> > > > if (!irq_work_claim(work))
> > > > return false;
> > > >
> > > > - /* Queue the entry and raise the IPI if needed. */
> > > > - preempt_disable();
> > > > + /* Check dynticks safely */
> > > > + local_irq_save(flags);
> > >
> > > Does not mention this ^
> > >
> > > 'sup?
> >
> > Because it's really just a technical detail.
> > If we enqueue before checking for tick stopped, we can avoid disabling irqs
> > because it's fine if we just raced with an irq in-between.
> >
> > But now that we enqueue _after_, we can't afford an IRQ in between.
> >
> > Should I update the comments maybe?
>
> Well, yes because it was entirely non-obvious, but maybe we can write it
> such that we can avoid the irq disable, because they're expensive.
>
> How about something like:
>
> if (work->flags & IRQ_WORK_LAZY) {
> if (llist_add(&work->llnode, __get_cpu_var(lazy_list)) &&
> tick_nohz_tick_stopped())
> arch_irq_work_raise();
> } else {
> if (llist_add(&work->llnode, __get_cpu_var(raise_list)))
> arch_irq_work_raise();
> }
>
> That way we check it after the enqueue.
Hmm, ok.
next prev parent reply other threads:[~2014-05-26 19:33 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-25 14:29 [PATCH 0/5] nohz: Move nohz kick out of scheduler IPI, v6 Frederic Weisbecker
2014-05-25 14:29 ` [PATCH 1/5] irq_work: Split raised and lazy lists Frederic Weisbecker
2014-05-26 15:59 ` Peter Zijlstra
2014-05-26 16:53 ` Frederic Weisbecker
2014-05-26 19:26 ` Peter Zijlstra
2014-05-26 19:33 ` Frederic Weisbecker [this message]
2014-05-25 14:29 ` [PATCH 2/5] irq_work: Shorten a bit irq_work_needs_cpu() Frederic Weisbecker
2014-05-25 14:29 ` [PATCH 3/5] irq_work: Implement remote queueing Frederic Weisbecker
2014-05-26 16:02 ` Peter Zijlstra
2014-05-26 16:50 ` Frederic Weisbecker
2014-05-26 19:19 ` Peter Zijlstra
2014-05-26 19:26 ` Frederic Weisbecker
2014-05-25 14:29 ` [PATCH 4/5] nohz: Move full nohz kick to its own IPI Frederic Weisbecker
2014-05-25 14:29 ` [PATCH 5/5] nohz: Use IPI implicit full barrier against rq->nr_running r/w Frederic Weisbecker
-- strict thread matches above, loose matches on Subject: below --
2014-06-03 14:40 [GIT PULL] nohz: Move nohz kick out of scheduler IPI, v7 Frederic Weisbecker
2014-06-03 14:40 ` [PATCH 1/5] irq_work: Split raised and lazy lists Frederic Weisbecker
2014-06-03 14:54 ` Peter Zijlstra
2014-06-03 14:56 ` Frederic Weisbecker
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=20140526193347.GJ2066@localhost.localdomain \
--to=fweisbec@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=khilman@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=viresh.kumar@linaro.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.