From: Eric Dumazet <dada1@cosmosbay.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Pavel Emelyanov <xemul@openvz.org>,
David Miller <davem@davemloft.net>,
Linux Netdev List <netdev@vger.kernel.org>,
devel@openvz.org
Subject: Re: [PATCH 0/5] Make nicer CONFIG_NET_NS=n case code
Date: Wed, 31 Oct 2007 23:40:59 +0100 [thread overview]
Message-ID: <4729047B.3080003@cosmosbay.com> (raw)
In-Reply-To: <m1hck7hrd1.fsf@ebiederm.dsl.xmission.com>
Eric W. Biederman a écrit :
> Eric Dumazet <dada1@cosmosbay.com> writes:
>
>
>> Definitly wanted here. Thank you.
>> One more refcounting on each socket creation/deletion was expensive.
>
> Really? Have you actually measured that? If the overhead is
> measurable and expensive we may want to look at per cpu counters or
> something like that. So far I don't have any numbers that say any
> of the network namespace work inherently has any overhead.
It seems that on some old opterons (two 246 for example),
"if (atomic_dec_and_test(&net->count))" is rather expensive yes :(
I am not sure per cpu counters help : I tried this and got no speedup. (This
was on net_device refcnt at that time)
(on this machines, the access through fs/gs selector seems expensive too)
Maybe a lazy mode could be done, ie only do a atomic_dec(), as done in dev_put() ?
Also, "count" sits in a cache line that contains mostly read and shared
fields, you might want to put it in a separate cache line in SMP, to avoid
cache line ping-pongs.
>
>> Maybe we can add a macro to get nd_net from a "struct net_device"
>> so that every instance of
>>
>> if (dev->nd_net != &init_net)
>> goto drop;
>>
>> can also be optimized away if !CONFIG_NET_NS
>
> Well that extra check should be removed once we finish converting
> those code paths. So I'm not too worried.
OK. Since the conditional test can be predicted by cpu, it certainly doesnt
matter.
>
> If this becomes a big issue I can dig up my old code that
> replaced struct net * with a net_t typedef and used functions
> for all of the comparisons and allowed everything to be compiled
> away.
>
> Trouble was it was sufficiently different that it was just enough
> different that people could not immediately understand the code.
>
next prev parent reply other threads:[~2007-10-31 22:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-31 19:19 [PATCH 0/5] Make nicer CONFIG_NET_NS=n case code Pavel Emelyanov
2007-10-31 18:49 ` Eric Dumazet
2007-10-31 21:35 ` Daniel Lezcano
2007-10-31 22:05 ` Eric W. Biederman
2007-10-31 22:40 ` Eric Dumazet [this message]
2007-10-31 23:31 ` David Miller
2007-11-01 0:58 ` Eric W. Biederman
2007-11-01 0:51 ` Eric W. Biederman
2007-11-01 6:58 ` Eric Dumazet
2007-11-01 7:02 ` David Miller
2007-10-31 19:23 ` [PATCH 1/5][NETNS] Make the init/exit hooks checks outside the loop Pavel Emelyanov
2007-11-01 7:43 ` David Miller
2007-10-31 19:25 ` [PATCH 2/5] Relax the reference counting of init_net_ns Pavel Emelyanov
2007-11-01 7:43 ` David Miller
2007-10-31 19:28 ` [PATCH 3/5] Hide the dead code in the net_namespace.c Pavel Emelyanov
2007-11-01 7:45 ` David Miller
2007-10-31 19:31 ` [PATCH 4/5] Mark the setup_net as __net_init Pavel Emelyanov
2007-11-01 7:46 ` David Miller
2007-10-31 19:32 ` [PATCH 5/5] Hide the net_ns kmem cache Pavel Emelyanov
2007-11-01 7:47 ` David Miller
2007-10-31 21:37 ` [PATCH 0/5] Make nicer CONFIG_NET_NS=n case code Daniel Lezcano
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=4729047B.3080003@cosmosbay.com \
--to=dada1@cosmosbay.com \
--cc=davem@davemloft.net \
--cc=devel@openvz.org \
--cc=ebiederm@xmission.com \
--cc=netdev@vger.kernel.org \
--cc=xemul@openvz.org \
/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).