From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Stephen Hemminger <shemminger@vyatta.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/4] fib_trie: print statistics for multiple tables
Date: Wed, 13 Feb 2008 14:26:27 -0800 [thread overview]
Message-ID: <20080213222627.GI12393@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080212183521.2c19e2a0.akpm@linux-foundation.org>
On Tue, Feb 12, 2008 at 06:35:21PM -0800, Andrew Morton wrote:
> On Tue, 12 Feb 2008 16:50:45 -0800 Stephen Hemminger <shemminger@vyatta.com> wrote:
>
> > +/**
> > + * hlist_for_each_entry_continue_rcu - iterate over rcu hlist after current point
> > + * @tpos: the type * to use as a loop cursor.
> > + * @pos: the &struct hlist_node to use as a loop cursor.
> > + * @member: the name of the hlist_node within the struct.
> > + */
> > +#define hlist_for_each_entry_continue_rcu(tpos, pos, member) \
> > + for (pos = (pos)->next; \
> > + rcu_dereference(pos) && ({ prefetch(pos->next); 1;}) && \
> > + ({ tpos = hlist_entry(pos, typeof(*tpos), member); 1;}); \
> > + pos = pos->next)
>
> Is the compiler allowed to look at a term such as
>
> ({ prefetch(pos->next); 1;})
>
> and, when it is used as a truth value, say "hey, that's always true" and
> then elide the call to prefetch()? We've no way of telling because this
> remains gcc-specific territory, afaik.
The prefetch() definitions I found are "asm volatile". So, as I
understand it, the compiler is not supposed to remove it, just as it
would not be permitted to remove something that could have a side effect.
> (cc Paul for rcu stuff)
Given my track record with simple functions of late :-/ I will beat this
one up a bit...
Thanx, Paul
next prev parent reply other threads:[~2008-02-13 22:26 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-13 0:50 [PATCH 0/4] fib_trie related patches for 2.6.25 Stephen Hemminger
2008-02-13 0:50 ` [PATCH 1/4] rcu_assign_pointer: null check fix Stephen Hemminger
2008-02-13 0:50 ` [PATCH 2/4] fib_trie: improve output format for /proc/net/fib_trie Stephen Hemminger
2008-02-13 2:28 ` Andrew Morton
2008-02-13 3:23 ` Stephen Hemminger
2008-02-13 0:50 ` [PATCH 3/4] fib_trie: print statistics for multiple tables Stephen Hemminger
2008-02-13 2:35 ` Andrew Morton
2008-02-13 22:26 ` Paul E. McKenney [this message]
2008-02-13 0:50 ` [PATCH 4/4] hlist_for_each_entry_continue simplification Stephen Hemminger
2008-02-13 1:26 ` David Miller
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=20080213222627.GI12393@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox