From: Peter Zijlstra <peterz@infradead.org>
To: Huang Ying <ying.huang@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -mm 1/2] irq_work, Use llist in irq_work
Date: Thu, 01 Sep 2011 09:58:47 +0200 [thread overview]
Message-ID: <1314863927.7945.11.camel@twins> (raw)
In-Reply-To: <4E5EFA08.30205@intel.com>
On Thu, 2011-09-01 at 11:20 +0800, Huang Ying wrote:
> On 09/01/2011 09:46 AM, Huang Ying wrote:
> >>> -static void __irq_work_queue(struct irq_work *entry)
> >>> +static void __irq_work_queue(struct irq_work *work)
> >>> {
> >>> - struct irq_work *next;
> >>> + struct irq_work_list *irq_work_list;
> >>>
> >>> - preempt_disable();
> >>> + irq_work_list = &get_cpu_var(irq_work_lists);
> >>>
> >>> - do {
> >>> - next = __this_cpu_read(irq_work_list);
> >>> - /* Can assign non-atomic because we keep the flags set. */
> >>> - entry->next = next_flags(next, IRQ_WORK_FLAGS);
> >>> - } while (this_cpu_cmpxchg(irq_work_list, next, entry) != next);
> >>> + llist_add(&work->llnode, &irq_work_list->llist);
> >>>
> >>> /* The list was empty, raise self-interrupt to start processing. */
> >>> - if (!irq_work_next(entry))
> >>> + if (!test_and_set_bit(LIST_NONEMPTY_BIT, &irq_work_list->flags))
> >>> arch_irq_work_raise();
> >>
> >> So why can't you simply test work->llnode->next?
> >
> > Yes. That is better. Even if there may be a small race window, it is
> > not a big issue to raise one extra self interrupt seldom.
>
> Remember something about this. I didn't test work->llnode->next here
> because I didn't want expose the implementation details like that here.
> How about make llist_add() return whether list is empty before adding?
> Because it will be an inline function, that should be optimized out if
> the caller do not need the information.
You could also use llist_empty() although that brings me to that
ACCESS_ONCE thing in there, what's the point?
next prev parent reply other threads:[~2011-09-01 7:58 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-30 5:16 [PATCH -mm 0/2] Use llist in irq_work and xlist Huang Ying
2011-08-30 5:16 ` [PATCH -mm 1/2] irq_work, Use llist in irq_work Huang Ying
2011-08-31 10:10 ` Peter Zijlstra
2011-09-01 1:46 ` Huang Ying
2011-09-01 3:20 ` Huang Ying
2011-09-01 7:58 ` Peter Zijlstra [this message]
2011-09-01 8:56 ` Huang Ying
2011-09-01 9:57 ` Peter Zijlstra
2011-09-02 1:14 ` Huang Ying
2011-09-03 17:35 ` Mathieu Desnoyers
2011-09-01 12:51 ` Mathieu Desnoyers
2011-09-01 13:00 ` Mathieu Desnoyers
2011-09-02 1:08 ` Huang Ying
2011-09-03 16:33 ` Mathieu Desnoyers
2011-09-01 7:57 ` Peter Zijlstra
2011-09-01 8:44 ` Huang Ying
2011-09-01 10:00 ` Peter Zijlstra
2011-09-02 1:18 ` Huang Ying
2011-09-02 13:26 ` Peter Zijlstra
2011-08-30 5:16 ` [PATCH -mm 2/2] net, rds, Replace xlist in net/rds/xlist.h with llist Huang Ying
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=1314863927.7945.11.camel@twins \
--to=peterz@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ying.huang@intel.com \
/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