| To: | Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: [5/6]: Dynamic neigh hash table growth |
| From: | "David S. Miller" <davem@xxxxxxxxxxxxx> |
| Date: | Mon, 27 Sep 2004 12:11:20 -0700 |
| Cc: | laforge@xxxxxxxxxxxx, netdev@xxxxxxxxxxx |
| In-reply-to: | <E1CBtl8-0000w8-00@gondolin.me.apana.org.au> |
| References: | <20040923225127.10b0ef68.davem@davemloft.net> <E1CBtl8-0000w8-00@gondolin.me.apana.org.au> |
| Sender: | netdev-bounce@xxxxxxxxxxx |
On Mon, 27 Sep 2004 21:33:34 +1000
Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote:
> David S. Miller <davem@xxxxxxxxxxxxx> wrote:
> >
> > +static void neigh_hash_grow(struct neigh_table *tbl, unsigned long
> > new_entries)
> > +{
> > + struct neighbour **new_hash, **old_hash;
> > + unsigned int i, new_hash_mask, old_entries;
> > +
> > + BUG_ON(new_entries & (new_entries - 1));
> > + new_hash = neigh_hash_alloc(new_entries);
>
> Perhaps it'd be better to bound it based on MAX_ORDER rather than waiting
> for neigh_hash_alloc() to fail?
After reading this email I was about to add the check,
but then again, __get_free_pages() handles this case
not all that suboptimally.
I don't think it'll be a problem in practice.
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [IPv4]: More fib_alias insertion fixes, David S. Miller |
|---|---|
| Next by Date: | Re: [6/6]: jenkins hash for neigh, David S. Miller |
| Previous by Thread: | Re: [5/6]: Dynamic neigh hash table growth, Herbert Xu |
| Next by Thread: | [6/6]: jenkins hash for neigh, David S. Miller |
| Indexes: | [Date] [Thread] [Top] [All Lists] |