netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, robert.olsson@its.uu.se, npiggin@suse.de
Subject: Re: [RFC PATCH]: Dynamically sized routing cache hash table.
Date: Tue, 06 Mar 2007 08:58:45 +0100	[thread overview]
Message-ID: <45ED1F35.4070600@cosmosbay.com> (raw)
In-Reply-To: <20070305.232329.95506510.davem@davemloft.net>

David Miller a écrit :
> 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.

Yes, but on bootup you have an appropriate NUMA active policy. (Well... we 
hope so, but it broke several time in the past)
I am not sure what kind of mm policy is active for scheduled works.

Anyway I have some XX GB machines, non NUMA, and I would love to be able to 
have a 2^20 slots hash table, without having to increase MAX_ORDER.

> 
> 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
> 


Yes, they are both wrong/dumb :)

Can we be smarter, or do we have to stay dumb ? :)

struct rt_hash_bucket *n = NULL;

	if (sz <= PAGE_SIZE) {
		n = kmalloc(sz, GFP_KERNEL);
		*kind = allocated_by_kmalloc;
	}
	else if (!hashdist) {
		n = (struct rt_hash_bucket *)
			__get_free_pages(GFP_KERNEL, get_order(sz));
		*kind = allocated_by_get_free_pages;
	}
	if (!n) {
		n = __vmalloc(sz, GFP_KERNEL, PAGE_KERNEL);
		*kind = allocated_by_vmalloc;
	}


  reply	other threads:[~2007-03-06  7:59 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
2007-03-06  7:58     ` Eric Dumazet [this message]
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=45ED1F35.4070600@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --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).