From: Marcelo <marcelo.leitner@gmail.com>
To: hejianet <hejianet@gmail.com>
Cc: netdev@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-kernel@vger.kernel.org, davem@davemloft.net,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
James Morris <jmorris@namei.org>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
Patrick McHardy <kaber@trash.net>,
Vlad Yasevich <vyasevich@gmail.com>,
Neil Horman <nhorman@tuxdriver.com>,
Steffen Klassert <steffen.klassert@secunet.com>,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [RFC PATCH v3 2/7] proc: Reduce cache miss in {snmp,netstat}_seq_show
Date: Wed, 14 Sep 2016 08:55:43 -0300 [thread overview]
Message-ID: <20160914115543.GF17689@localhost.localdomain> (raw)
In-Reply-To: <22d87ec3-608f-fe41-5eb7-fe1104f133dd@gmail.com>
Hi Jia,
On Wed, Sep 14, 2016 at 01:58:42PM +0800, hejianet wrote:
> Hi Marcelo
>
>
> On 9/13/16 2:57 AM, Marcelo wrote:
> > On Fri, Sep 09, 2016 at 02:33:57PM +0800, Jia He wrote:
> > > This is to use the generic interface snmp_get_cpu_field{,64}_batch to
> > > aggregate the data by going through all the items of each cpu sequentially.
> > > Then snmp_seq_show and netstat_seq_show are split into 2 parts to avoid build
> > > warning "the frame size" larger than 1024 on s390.
> > Yeah about that, did you test it with stack overflow detection?
> > These arrays can be quite large.
> >
> > One more below..
> Do you think it is acceptable if the stack usage is a little larger than 1024?
> e.g. 1120
> I can't find any other way to reduce the stack usage except use "static" before
> unsigned long buff[TCP_MIB_MAX]
>
> PS. sizeof buff is about TCP_MIB_MAX(116)*8=928
> B.R.
That's pretty much the question. Linux has the option on some archs to
run with 4Kb (4KSTACKS option), so this function alone would be using
25% of it in this last case. While on x86_64, it uses 16Kb (6538b8ea886e
("x86_64: expand kernel stack to 16K")).
Adding static to it is not an option as it actually makes the variable
shared amongst the CPUs (and then you have concurrency issues), plus the
fact that it's always allocated, even while not in use.
Others here certainly know better than me if it's okay to make such
usage of the stach.
> > > +static int netstat_seq_show_ipext(struct seq_file *seq, void *v)
> > > +{
> > > + int i;
> > > + u64 buff64[IPSTATS_MIB_MAX];
> > > + struct net *net = seq->private;
> > > seq_puts(seq, "\nIpExt:");
> > > for (i = 0; snmp4_ipextstats_list[i].name != NULL; i++)
> > > seq_printf(seq, " %s", snmp4_ipextstats_list[i].name);
> > > seq_puts(seq, "\nIpExt:");
> > You're missing a memset() call here.
Not sure if you missed this one or not..
Thanks,
Marcelo
next prev parent reply other threads:[~2016-09-14 11:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-09 6:33 [RFC PATCH v3 0/7] Reduce cache miss for snmp_fold_field Jia He
2016-09-09 6:33 ` [RFC PATCH v3 1/7] net:snmp: Introduce generic batch interfaces for snmp_get_cpu_field{,64} Jia He
2016-09-09 6:33 ` [RFC PATCH v3 2/7] proc: Reduce cache miss in {snmp,netstat}_seq_show Jia He
2016-09-12 18:57 ` Marcelo
2016-09-14 3:10 ` hejianet
2016-09-14 5:58 ` hejianet
2016-09-14 11:55 ` Marcelo [this message]
2016-09-21 16:18 ` hejianet
2016-09-21 18:24 ` Marcelo
2016-09-22 5:38 ` hejianet
2016-09-09 6:33 ` [RFC PATCH v3 3/7] proc: Reduce cache miss in snmp6_seq_show Jia He
2016-09-12 19:05 ` Marcelo
2016-09-14 3:11 ` hejianet
2016-09-09 6:33 ` [RFC PATCH v3 4/7] proc: Reduce cache miss in sctp_snmp_seq_show Jia He
2016-09-09 6:34 ` [RFC PATCH v3 5/7] proc: Reduce cache miss in xfrm_statistics_seq_show Jia He
2016-09-09 6:34 ` [RFC PATCH v3 6/7] ipv6: Remove useless parameter in __snmp6_fill_statsdev Jia He
2016-09-09 6:34 ` [RFC PATCH v3 7/7] net: Suppress the "Comparison to NULL could be written" warning Jia He
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=20160914115543.GF17689@localhost.localdomain \
--to=marcelo.leitner@gmail.com \
--cc=davem@davemloft.net \
--cc=hejianet@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=jmorris@namei.org \
--cc=kaber@trash.net \
--cc=kuznet@ms2.inr.ac.ru \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sctp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=steffen.klassert@secunet.com \
--cc=vyasevich@gmail.com \
--cc=yoshfuji@linux-ipv6.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).