From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
To: Eric Wong <normalperson@yhbt.net>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Stephen Hemminger <shemminger@vyatta.com>,
Davide Libenzi <davidel@xmailserver.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] wfcqueue: functions for local append and enqueue
Date: Sat, 23 Mar 2013 15:43:10 -0400 [thread overview]
Message-ID: <20130323194309.GA32464@Krystal> (raw)
In-Reply-To: <20130323190726.GA30029@dcvr.yhbt.net>
* Eric Wong (normalperson@yhbt.net) wrote:
> With level-triggered epoll, append/enqueue operations to the
> local/locked queues increase performance by avoiding unnecessary atomic
> operations and barriers. These are necessary to avoid performance
> regressions when looping through ep_send_events and appending many
> items to a local queue.
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Stephen Hemminger <shemminger@vyatta.com>
> Cc: Davide Libenzi <davidel@xmailserver.org>
> ---
> I noticed the original __wfcq_append function was not in the
> synchronization table, so I left out ___wfcq_append from the table
> as well.
>
> include/linux/wfcqueue.h | 59 ++++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 52 insertions(+), 7 deletions(-)
>
> diff --git a/include/linux/wfcqueue.h b/include/linux/wfcqueue.h
> index 9464a0c..800b1dd 100644
> --- a/include/linux/wfcqueue.h
> +++ b/include/linux/wfcqueue.h
> @@ -55,14 +55,16 @@
> * [4] __wfcq_splice (source queue)
> * [5] __wfcq_first
> * [6] __wfcq_next
> + * [7] __wfcq_enqueue
> *
> - * [1] [2] [3] [4] [5] [6]
> - * [1] - - - - - -
> - * [2] - - - - - -
> - * [3] - - X X X X
> - * [4] - - X - X X
> - * [5] - - X X - -
> - * [6] - - X X - -
> + * [1] [2] [3] [4] [5] [6] [7]
> + * [1] - - - - - - X
> + * [2] - - - - - - X
> + * [3] - - X X X X X
> + * [4] - - X - X X X
> + * [5] - - X X - - X
> + * [6] - - X X - - X
> + * [7] X X X X X X X
> *
> * Besides locking, mutual exclusion of dequeue, splice and iteration
> * can be ensured by performing all of those operations from a single
> @@ -205,6 +207,49 @@ static inline bool wfcq_enqueue(struct wfcq_head *head,
> }
>
> /*
> + * ___wfcq_append: append one local queue to another local queue
> + *
> + * No memory barriers are issued. Mutual exclusion is the responsibility
> + * of the caller.
> + *
> + * Returns false if the queue was empty prior to adding the node.
> + * Returns true otherwise.
> + */
__wfcq_append() and ___wfcq_append() are meant to be private to
wfcqueue.h. Therefore, the comment above should be removed, since it is
not part of the API.
I notice that I should have used ___wfcq_append() for the original
append function for consistency (other private helpers in this header
are prefixed with ___).
So maybe we should rename __wfcq_append to ___wfcq_append (making it
clear that it is a private helper), and introduce your helper as
___wfcq_append_local() (I don't care about having "local" in there since
it is not part of the exposed API).
> +static inline bool ___wfcq_append(struct wfcq_head *head,
> + struct wfcq_tail *tail,
> + struct wfcq_node *new_head,
> + struct wfcq_node *new_tail)
> +{
> + struct wfcq_node *old_tail;
> +
> + old_tail = tail->p;
> + tail->p = new_tail;
> + old_tail->next = new_head;
> +
> + /*
> + * Return false if queue was empty prior to adding the node,
> + * else return true.
> + */
> + return old_tail != &head->node;
> +}
> +
> +/*
> + * __wfcq_enqueue: enqueue a node into a local queue
The concept of "local queue" is not clearly defined.
Perhaps it would be clearer to state:
* __wfcq_enqueue: enqueue a node into a queue, requiring mutual exclusion.
Thoughts ?
Thanks,
Mathieu
> + *
> + * No memory barriers are issued. Mutual exclusion is the responsibility
> + * of the caller.
> + *
> + * Returns false if the queue was empty prior to adding the node.
> + * Returns true otherwise.
> + */
> +static inline bool __wfcq_enqueue(struct wfcq_head *head,
> + struct wfcq_tail *tail,
> + struct wfcq_node *new_tail)
> +{
> + return ___wfcq_append(head, tail, new_tail, new_tail);
> +}
> +
> +/*
> * ___wfcq_busy_wait: busy-wait.
> */
> static inline void ___wfcq_busy_wait(void)
> --
> 1.8.2.rc3.2.geae6cf5
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
next prev parent reply other threads:[~2013-03-23 19:43 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-11 21:36 [RFC PATCH] Linux kernel Wait-Free Concurrent Queue Implementation Mathieu Desnoyers
2013-03-14 4:22 ` Eric Wong
2013-03-14 13:18 ` Mathieu Desnoyers
2013-03-14 19:07 ` Eric Wong
2013-03-14 19:48 ` Mathieu Desnoyers
2013-03-14 21:32 ` Eric Wong
2013-03-15 2:38 ` Mathieu Desnoyers
2013-03-16 22:02 ` Eric Wong
2013-03-17 2:03 ` Mathieu Desnoyers
2013-03-18 10:37 ` Eric Wong
2013-03-15 0:49 ` Peter Hurley
2013-03-15 2:08 ` Mathieu Desnoyers
2013-03-21 11:43 ` [PATCH] wfcqueue: functions for local append and enqueue Eric Wong
2013-03-22 2:01 ` Mathieu Desnoyers
2013-03-22 10:31 ` Eric Wong
2013-03-23 19:07 ` [PATCH v2] " Eric Wong
2013-03-23 19:43 ` Mathieu Desnoyers [this message]
2013-03-23 20:42 ` [PATCH v3] " Eric Wong
2013-03-23 22:10 ` Mathieu Desnoyers
2013-03-29 8:10 ` [PATCH] wfcqueue: add function for unsynchronized prepend Eric Wong
2013-04-02 13:05 ` Mathieu Desnoyers
2013-04-02 21:15 ` Eric Wong
2013-04-06 21:42 ` [RFC PATCH] wfcqueue: implement __wfcq_enqueue_head() Mathieu Desnoyers
2013-04-11 21:23 ` [RFC PATCH] Linux kernel Wait-Free Concurrent Queue Implementation Eric Wong
2013-04-11 22:44 ` Mathieu Desnoyers
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=20130323194309.GA32464@Krystal \
--to=mathieu.desnoyers@efficios.com \
--cc=davidel@xmailserver.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=normalperson@yhbt.net \
--cc=paulmck@linux.vnet.ibm.com \
--cc=shemminger@vyatta.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 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.