From: "Timo Teräs" <timo.teras@iki.fi>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Herbert Xu <herbert@gondor.apana.org.au>, netdev@vger.kernel.org
Subject: Re: [PATCH 3/7] flow: allocate hash table for online cpus only
Date: Wed, 31 Mar 2010 16:27:36 +0300 [thread overview]
Message-ID: <4BB34DC8.7080903@iki.fi> (raw)
In-Reply-To: <201003312302.51683.rusty@rustcorp.com.au>
Rusty Russell wrote:
> On Tue, 30 Mar 2010 10:42:55 pm Herbert Xu wrote:
>> On Mon, Mar 29, 2010 at 05:12:40PM +0300, Timo Teras wrote:
>>> Instead of unconditionally allocating hash table for all possible
>>> cpu's, allocate it only for online cpu's and release related
>>> memory if cpu goes down.
>>>
>>> Signed-off-by: Timo Teras <timo.teras@iki.fi>
>> Hmm that's where we started but then Rusty changed it back in 2004:
>>
>> So I'd like to hear his opinion on changing it back again.
>
> It was pretty unique at the time, it no longer is, so the arguments are less
> compelling IMHO.
>
> However, we can now use a dynamic percpu variable and get it as a real
> per-cpu thing (which currently means it *will* be for every available cpu,
> not just online ones). Haven't thought about it, but that change might be
> worth considering instead?
I did convert most of the static percpu variables to a struct which
is allocated dynamically using alloc_percpu. See:
http://marc.info/?l=linux-netdev&m=127003066905912&w=2
This patch is on top of that, to avoid allocating the larger hash
table unconditionally as amount of possible cpu's can be large.
If you take a look at the actual patch to add back the hash allocation
for only 'online' cpu's, it's not that complicated IMHO:
http://marc.info/?l=linux-netdev&m=126987200927472&w=2
next prev parent reply other threads:[~2010-03-31 13:27 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-29 14:12 [PATCH 0/7] caching bundles, iteration 2 Timo Teras
2010-03-29 14:12 ` [PATCH 1/7] xfrm: remove policy lock when accessing policy->walk.dead Timo Teras
2010-03-29 14:43 ` Herbert Xu
2010-03-30 4:55 ` Timo Teräs
2010-03-30 11:53 ` Herbert Xu
2010-03-30 12:04 ` Timo Teräs
2010-03-30 12:14 ` Herbert Xu
2010-03-30 12:21 ` Timo Teräs
2010-03-30 12:23 ` Herbert Xu
2010-03-30 12:41 ` Timo Teräs
2010-03-30 12:48 ` Herbert Xu
2010-03-30 13:33 ` Timo Teräs
2010-03-30 14:30 ` Herbert Xu
2010-03-30 14:34 ` Herbert Xu
2010-03-30 14:37 ` Herbert Xu
2010-03-30 14:01 ` Timo Teräs
2010-03-30 14:29 ` Herbert Xu
2010-03-30 15:36 ` Timo Teräs
2010-03-31 0:43 ` Herbert Xu
2010-03-29 14:12 ` [PATCH 2/7] flow: structurize flow cache Timo Teras
2010-03-30 12:01 ` Herbert Xu
2010-03-30 12:02 ` Timo Teräs
2010-03-30 12:15 ` Herbert Xu
2010-03-29 14:12 ` [PATCH 3/7] flow: allocate hash table for online cpus only Timo Teras
2010-03-30 12:12 ` Herbert Xu
2010-03-31 12:32 ` Rusty Russell
2010-03-31 13:27 ` Timo Teräs [this message]
2010-03-29 14:12 ` [PATCH 4/7] flow: delayed deletion of flow cache entries Timo Teras
2010-03-30 12:22 ` Herbert Xu
2010-03-30 12:32 ` Timo Teräs
2010-03-30 12:36 ` Herbert Xu
2010-03-30 12:43 ` Timo Teräs
2010-03-29 14:12 ` [PATCH 5/7] flow: virtualize get and entry deletion methods Timo Teras
2010-03-29 14:12 ` [PATCH 6/7] xfrm: cache bundles instead of policies for outgoing flows Timo Teras
2010-03-29 14:12 ` [PATCH 7/7] xfrm: remove policy garbage collection Timo Teras
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=4BB34DC8.7080903@iki.fi \
--to=timo.teras@iki.fi \
--cc=herbert@gondor.apana.org.au \
--cc=netdev@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.