From: David Miller <davem@davemloft.net>
To: dada1@cosmosbay.com
Cc: netdev@vger.kernel.org, robert.olsson@its.uu.se, npiggin@suse.de
Subject: Re: [RFC PATCH]: Dynamically sized routing cache hash table.
Date: Mon, 05 Mar 2007 23:23:29 -0800 (PST) [thread overview]
Message-ID: <20070305.232329.95506510.davem@davemloft.net> (raw)
In-Reply-To: <45ED14E6.7090109@cosmosbay.com>
From: Eric Dumazet <dada1@cosmosbay.com>
Date: Tue, 06 Mar 2007 08:14:46 +0100
> I wonder... are you sure this has no relation with the size of rt_hash_locks /
> RT_HASH_LOCK_SZ ?
> One entry must have the same lock in the two tables when resizing is in flight.
> #define MIN_RTHASH_SHIFT LOG2(RT_HASH_LOCK_SZ)
Good point.
> > +static struct rt_hash_bucket *rthash_alloc(unsigned int sz)
> > +{
> > + struct rt_hash_bucket *n;
> > +
> > + if (sz <= PAGE_SIZE)
> > + n = kmalloc(sz, GFP_KERNEL);
> > + else if (hashdist)
> > + n = __vmalloc(sz, GFP_KERNEL, PAGE_KERNEL);
> > + else
> > + n = (struct rt_hash_bucket *)
> > + __get_free_pages(GFP_KERNEL, get_order(sz));
>
> I dont feel well with this.
> Maybe we could try a __get_free_pages(), and in case of failure, fallback to
> vmalloc(). Then keep a flag to be able to free memory correctly. Anyway, if
> (get_order(sz)>=MAX_ORDER) we know __get_free_pages() will fail.
We have to use vmalloc() for the hashdist case so that the pages
are spread out properly on NUMA systems. That's exactly what the
large system hash allocator is going to do on bootup anyways.
Look, either both are right or both are wrong. I'm just following
protocol above and you'll note the PRECISE same logic exists in other
dynamically growing hash table implementations such as
net/xfrm/xfrm_hash.c
> Could you add const qualifiers to 'struct rt_hash *' in prototypes where
> appropriate ?
Sure, no problem.
> Maybe that for small tables (less than PAGE_SIZE/2), we could embed them in
> 'struct rt_hash'
Not worth the pain nor the in-kernel-image-space it would chew up,
in my opinion.
After you visit a handful of web sites you'll get beyond that
threshold.
> Could we group all static vars at the begining of this file, so that we
> clearly see where we should place them, to avoid false sharing.
Sure.
> > +
> > +static void rt_hash_resize(unsigned int new_shift)
Damn, please don't quote such huge portions of a patch without any
comments, this has to go out to several thousand recipients you know
:-/
next prev parent reply other threads:[~2007-03-06 7:23 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-06 4:26 [RFC PATCH]: Dynamically sized routing cache hash table David Miller
2007-03-06 7:14 ` Eric Dumazet
2007-03-06 7:23 ` David Miller [this message]
2007-03-06 7:58 ` Eric Dumazet
2007-03-06 9:05 ` David Miller
2007-03-06 10:33 ` [PATCH] NET : Optimizes inet_getpeer() Eric Dumazet
2007-03-07 4:23 ` David Miller
2007-03-06 13:42 ` [RFC PATCH]: Dynamically sized routing cache hash table Robert Olsson
2007-03-06 14:18 ` Eric Dumazet
2007-03-06 17:05 ` Robert Olsson
2007-03-06 17:20 ` Eric Dumazet
2007-03-06 18:55 ` Robert Olsson
2007-03-06 9:11 ` Nick Piggin
2007-03-06 9:17 ` David Miller
2007-03-06 9:22 ` Nick Piggin
2007-03-06 9:23 ` Eric Dumazet
2007-03-06 9:41 ` Nick Piggin
2007-03-06 13:26 ` Robert Olsson
2007-03-06 22:20 ` David Miller
2007-03-08 6:26 ` Nick Piggin
2007-03-08 13:35 ` Robert Olsson
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=20070305.232329.95506510.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=dada1@cosmosbay.com \
--cc=netdev@vger.kernel.org \
--cc=npiggin@suse.de \
--cc=robert.olsson@its.uu.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).