From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Jarek Poplawski <jarkao2@gmail.com>
Cc: "Robert Olsson" <robert@robur.slu.se>,
"Robert Olsson" <Robert.Olsson@data.slu.se>,
"Eric Dumazet" <dada1@cosmosbay.com>,
=?ISO-8859-2?Q?Pawe=B3_Staszewski?= <pstaszewski@itcare.pl>,
"Robert Olsson" <robert.olsson@its.uu.se>,
"Linux Network Development list" <netdev@vger.kernel.org>
Subject: Re: rib_trie / Fix inflate_threshold_root. Now=15 size=11 bits
Date: Fri, 26 Jun 2009 09:23:40 -0700 [thread overview]
Message-ID: <20090626162340.GF6771@linux.vnet.ibm.com> (raw)
In-Reply-To: <20090626161500.GB6526@ami.dom.local>
On Fri, Jun 26, 2009 at 06:15:00PM +0200, Jarek Poplawski wrote:
> On Fri, Jun 26, 2009 at 05:54:10PM +0200, Jarek Poplawski wrote:
> > On Fri, Jun 26, 2009 at 08:30:10AM -0700, Paul E. McKenney wrote:
> > > On Fri, Jun 26, 2009 at 05:10:52PM +0200, Jarek Poplawski wrote:
> > > > On Fri, Jun 26, 2009 at 03:52:55PM +0200, Robert Olsson wrote:
> > > > >
> > > > > Jarek Poplawski writes:
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Should be worth testing so we synchronize_rcu instead of doing call_rcu's
> > > > >
> > > >
> > > > Alas take 2 (nor 1) doesn't compile, so here it is again.
> > >
> > > So the idea is to balance memory and latency, so that large changes
> > > (those affecting the root node) get at least one synchronize_rcu(),
> > > while smaller changes just use call_rcu(), correct? This means that
> > > the amount of memory awaiting an RCU grace period is limited, but
> > > the algorithm avoids per-node synchronize_rcu() overhead.
> > >
> > > If I understand the goal correctly, looks good! (Give or take my
> > > limited understanding of fib_trie and is usage, of course.)
> >
> > The goal is practically to replace all call_rcu() during
> > trie_rebalance() with synchronize_rcu() (except some freeing after
> > ENOMEM). I guess currently (<= 2.6.30) call_rcu() can free this
> > memory after trie_rebalance() has finished, that's why there were
> > problems with enabled preemption. So this patch tries to do/force
> > this a bit earlier - at least before the top/largest node is
> > rebalanced.
>
> On the other hand, we could probably stay with call_rcu() plus only
> one synchronize_rcu() before the top node's resize() if you think it's
> enough here?
Well, my first task is to understand the problem/goal. ;-)
My guess from what you said above is that use of call_rcu(), when
combined with changes to the trie in rapid succession, is resulting
in excessive memory awaiting a grace period. Is this the case, or am I
confused?
Thanx, Paul
> Thanks,
> Jarek P.
>
> >
> > >
> > > Thanx, Paul
> > >
> > > > Thanks,
> > > > Jarek P.
> > > > --- (take 3 - for testing)
> > > >
> > > > net/ipv4/fib_trie.c | 30 ++++++++++++++++++++++++------
> > > > 1 files changed, 24 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
> > > > index 012cf5a..1a4c4b7 100644
> > > > --- a/net/ipv4/fib_trie.c
> > > > +++ b/net/ipv4/fib_trie.c
> > > > @@ -366,6 +366,17 @@ static void __tnode_vfree(struct work_struct *arg)
> > > > vfree(tn);
> > > > }
> > > >
> > > > +static void __tnode_free(struct tnode *tn)
> > > > +{
> > > > + size_t size = sizeof(struct tnode) +
> > > > + (sizeof(struct node *) << tn->bits);
> > > > +
> > > > + if (size <= PAGE_SIZE)
> > > > + kfree(tn);
> > > > + else
> > > > + vfree(tn);
> > > > +}
> > > > +
> > > > static void __tnode_free_rcu(struct rcu_head *head)
> > > > {
> > > > struct tnode *tn = container_of(head, struct tnode, rcu);
> > > > @@ -402,7 +413,7 @@ static void tnode_free_flush(void)
> > > > while ((tn = tnode_free_head)) {
> > > > tnode_free_head = tn->tnode_free;
> > > > tn->tnode_free = NULL;
> > > > - tnode_free(tn);
> > > > + __tnode_free(tn);
> > > > }
> > > > }
> > > >
> > > > @@ -1021,18 +1032,25 @@ static void trie_rebalance(struct trie *t, struct tnode *tn)
> > > > (struct node *)tn, wasfull);
> > > >
> > > > tp = node_parent((struct node *) tn);
> > > > - tnode_free_flush();
> > > > if (!tp)
> > > > break;
> > > > tn = tp;
> > > > }
> > > >
> > > > + if (tnode_free_head) {
> > > > + synchronize_rcu();
> > > > + tnode_free_flush();
> > > > + }
> > > > +
> > > > /* Handle last (top) tnode */
> > > > - if (IS_TNODE(tn))
> > > > + if (IS_TNODE(tn)) {
> > > > tn = (struct tnode *)resize(t, (struct tnode *)tn);
> > > > -
> > > > - rcu_assign_pointer(t->trie, (struct node *)tn);
> > > > - tnode_free_flush();
> > > > + rcu_assign_pointer(t->trie, (struct node *)tn);
> > > > + synchronize_rcu();
> > > > + tnode_free_flush();
> > > > + } else {
> > > > + rcu_assign_pointer(t->trie, (struct node *)tn);
> > > > + }
> > > >
> > > > return;
> > > > }
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-06-26 16:23 UTC|newest]
Thread overview: 99+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-25 15:48 rib_trie / Fix inflate_threshold_root. Now=15 size=11 bits Paweł Staszewski
2009-06-25 21:19 ` Eric Dumazet
2009-06-25 21:52 ` Paweł Staszewski
2009-06-25 22:54 ` Eric Dumazet
2009-06-26 10:06 ` Paweł Staszewski
2009-06-26 10:34 ` Eric Dumazet
2009-06-26 10:47 ` Paweł Staszewski
2009-06-26 10:52 ` Eric Dumazet
2009-06-26 17:26 ` Paweł Staszewski
2009-06-26 8:03 ` Jarek Poplawski
2009-06-26 9:19 ` Robert Olsson
2009-06-26 9:37 ` Jarek Poplawski
2009-06-26 10:26 ` Jorge Boncompte [DTI2]
2009-06-26 12:42 ` Robert Olsson
2009-06-26 12:54 ` Jarek Poplawski
2009-06-26 13:28 ` Jarek Poplawski
2009-06-26 13:52 ` Robert Olsson
2009-06-26 15:10 ` Jarek Poplawski
2009-06-26 15:30 ` Paul E. McKenney
2009-06-26 15:54 ` Jarek Poplawski
2009-06-26 16:15 ` Jarek Poplawski
2009-06-26 16:23 ` Paul E. McKenney [this message]
2009-06-26 16:45 ` Jarek Poplawski
2009-06-26 17:05 ` Paul E. McKenney
2009-06-26 18:05 ` Jarek Poplawski
2009-06-26 18:21 ` Paul E. McKenney
2009-06-26 20:19 ` Jarek Poplawski
2009-06-26 20:26 ` Robert Olsson
2009-06-26 20:37 ` Jarek Poplawski
2009-06-26 21:20 ` Jarek Poplawski
2009-06-27 19:20 ` Jarek Poplawski
2009-06-27 20:51 ` Jarek Poplawski
2009-06-28 0:28 ` Paweł Staszewski
2009-06-28 11:11 ` Robert Olsson
2009-06-29 7:57 ` Paweł Staszewski
2009-06-28 11:04 ` Robert Olsson
2009-06-28 12:03 ` Jarek Poplawski
2009-06-28 14:35 ` Jarek Poplawski
2009-06-28 15:32 ` Paweł Staszewski
2009-06-28 15:48 ` Paweł Staszewski
2009-06-28 19:56 ` Jarek Poplawski
2009-06-28 21:36 ` Jarek Poplawski
2009-06-29 8:08 ` Paweł Staszewski
2009-06-29 8:47 ` Paweł Staszewski
2009-06-29 9:27 ` Jarek Poplawski
2009-06-29 9:43 ` Paweł Staszewski
2009-06-29 8:33 ` [PATCH net-2.6] " Jarek Poplawski
2009-06-29 9:51 ` Paweł Staszewski
2009-06-29 10:47 ` Jarek Poplawski
2009-06-29 16:24 ` Paweł Staszewski
2009-06-29 17:09 ` Jarek Poplawski
2009-06-30 7:09 ` Jarek Poplawski
2009-06-30 20:16 ` Paweł Staszewski
2009-06-30 20:41 ` Jarek Poplawski
2009-06-30 23:31 ` Paweł Staszewski
2009-07-01 6:36 ` Jarek Poplawski
[not found] ` <20090701072409.GA12592@ff.dom.local>
2009-07-01 9:43 ` Paweł Staszewski
2009-07-01 9:50 ` Paweł Staszewski
2009-07-01 10:13 ` Jarek Poplawski
2009-07-01 11:04 ` Jarek Poplawski
2009-07-01 22:17 ` Paweł Staszewski
2009-07-02 5:32 ` Jarek Poplawski
2009-07-02 5:43 ` Paweł Staszewski
2009-07-02 6:00 ` Jarek Poplawski
2009-07-02 15:31 ` Robert Olsson
2009-07-02 19:06 ` Jarek Poplawski
2009-07-02 21:32 ` Robert Olsson
2009-07-02 22:13 ` Jarek Poplawski
2009-07-05 0:26 ` Paweł Staszewski
2009-07-05 0:30 ` Paweł Staszewski
2009-07-05 16:20 ` Jarek Poplawski
2009-07-05 17:32 ` Jarek Poplawski
2009-07-05 21:32 ` Paul E. McKenney
2009-07-05 22:23 ` Jarek Poplawski
2009-07-05 23:53 ` Paweł Staszewski
2009-07-06 9:02 ` Jarek Poplawski
2009-07-07 22:56 ` Paweł Staszewski
2009-07-07 23:50 ` Jarek Poplawski
2009-07-09 20:34 ` Paweł Staszewski
2009-07-14 19:41 ` [PATCH net-next] " Jarek Poplawski
2009-07-15 7:43 ` Robert Olsson
2009-07-15 13:05 ` Jarek Poplawski
2009-07-17 8:08 ` Robert Olsson
2009-07-20 14:41 ` David Miller
2009-07-07 23:23 ` [PATCH net-2.6] " Paweł Staszewski
2009-07-07 23:30 ` Paweł Staszewski
2009-07-14 18:33 ` [PATCH net-next] " Jarek Poplawski
2009-07-20 14:41 ` David Miller
2009-07-14 21:20 ` [PATCH net-next] ipv4: fib_trie: Use tnode_get_child_rcu() and node_parent_rcu() in lookups Jarek Poplawski
2009-07-20 14:41 ` David Miller
2009-07-05 0:31 ` [PATCH net-2.6] Re: rib_trie / Fix inflate_threshold_root. Now=15 size=11 bits Paweł Staszewski
2009-07-05 12:56 ` [PATCH -stable] " Jarek Poplawski
2009-07-05 13:08 ` [PATCH v2 " Jarek Poplawski
2009-07-08 2:42 ` David Miller
2009-07-08 6:44 ` Jarek Poplawski
2009-06-29 10:58 ` [PATCH net-2.6] " Jarek Poplawski
2009-06-30 19:48 ` David Miller
2009-06-30 20:14 ` Jarek Poplawski
2009-07-10 15:29 ` Stephen Hemminger
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=20090626162340.GF6771@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Robert.Olsson@data.slu.se \
--cc=dada1@cosmosbay.com \
--cc=jarkao2@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pstaszewski@itcare.pl \
--cc=robert.olsson@its.uu.se \
--cc=robert@robur.slu.se \
/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;
as well as URLs for NNTP newsgroup(s).