From: Joe Perches <joe@perches.com>
To: "Drokin, Oleg" <oleg.drokin@intel.com>
Cc: James Simmons <jsimmons@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"<devel@driverdev.osuosl.org>" <devel@driverdev.osuosl.org>,
"Dilger, Andreas" <andreas.dilger@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Lustre Development List <lustre-devel@lists.lustre.org>,
"Nunez, James A" <james.a.nunez@intel.com>
Subject: [lustre-devel] [PATCH 1/6] staging: lustre: Correct missing newline for CERROR call in sfw_handle_server_rpc
Date: Sat, 12 Mar 2016 10:56:29 -0800 [thread overview]
Message-ID: <1457808989.11972.22.camel@perches.com> (raw)
In-Reply-To: <5A0A38B8-B387-436D-B72A-7D8247B6A00D@intel.com>
On Sat, 2016-03-12 at 18:32 +0000, Drokin, Oleg wrote:
> On Mar 12, 2016, at 1:23 PM, Joe Perches wrote:
> > On Sat, 2016-03-12 at 13:00 -0500, James Simmons wrote:
> > > From: James Nunez <james.a.nunez@intel.com>
> > >
> > > This is one of the fixes broken out of patch 10000 that was
> > > missed in the merger. With this fix the CERROR called in
> > > sfw_handle_server_rpc will print out correctly.
> > Speaking of CERROR and logging, it it really useful
> > for each CERROR use to have 2 static structs?
> >
> > In CERROR -> CDEBUG_LIMIT there is a:
> > static struct cfs_debug_limit_state cdls;
> > (12 or 16 bytes depending on 32/64 bit arch)
> >
> > and in CDEBUG_LIMIT -> _CDEBUG
> > static struct libcfs_debug_msg_data msgdata;
> > (24 or 36 bytes depending on 32/64 bit arch)
> >
> > That seems a largish bit of data and code to initialize
> > these structs for over a thousand call sites.
> >
> > Wouldn't a single static suffice?
> Single static would not work because the code is parallel so it'll
> stomp over each other.
Sure,?but?would that matter in practice?
net_ratelimit() has similar parallelization and it doesn't
seem to matter there.
> or do you mean to have a common
> structure for every callsite (but instantiated separately)?
That might help a tiny bit.
Some possibly unnecessary bits:
o .msg_cdls
o __FILE__, __func__ and __LINE__ fields have marginal value
o .msg_subsys seems set only to DEBUG_SUBSYSTEM.
> This used to be a local structure in the past, but that
> caused considerable stack growth for some functions, that added
> up along the call chain, and that was the solution we came up with
> that did help.
WARNING: multiple messages have this Message-ID (diff)
From: Joe Perches <joe@perches.com>
To: "Drokin, Oleg" <oleg.drokin@intel.com>
Cc: James Simmons <jsimmons@infradead.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"<devel@driverdev.osuosl.org>" <devel@driverdev.osuosl.org>,
"Dilger, Andreas" <andreas.dilger@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Lustre Development List <lustre-devel@lists.lustre.org>,
"Nunez, James A" <james.a.nunez@intel.com>
Subject: Re: [PATCH 1/6] staging: lustre: Correct missing newline for CERROR call in sfw_handle_server_rpc
Date: Sat, 12 Mar 2016 10:56:29 -0800 [thread overview]
Message-ID: <1457808989.11972.22.camel@perches.com> (raw)
In-Reply-To: <5A0A38B8-B387-436D-B72A-7D8247B6A00D@intel.com>
On Sat, 2016-03-12 at 18:32 +0000, Drokin, Oleg wrote:
> On Mar 12, 2016, at 1:23 PM, Joe Perches wrote:
> > On Sat, 2016-03-12 at 13:00 -0500, James Simmons wrote:
> > > From: James Nunez <james.a.nunez@intel.com>
> > >
> > > This is one of the fixes broken out of patch 10000 that was
> > > missed in the merger. With this fix the CERROR called in
> > > sfw_handle_server_rpc will print out correctly.
> > Speaking of CERROR and logging, it it really useful
> > for each CERROR use to have 2 static structs?
> >
> > In CERROR -> CDEBUG_LIMIT there is a:
> > static struct cfs_debug_limit_state cdls;
> > (12 or 16 bytes depending on 32/64 bit arch)
> >
> > and in CDEBUG_LIMIT -> _CDEBUG
> > static struct libcfs_debug_msg_data msgdata;
> > (24 or 36 bytes depending on 32/64 bit arch)
> >
> > That seems a largish bit of data and code to initialize
> > these structs for over a thousand call sites.
> >
> > Wouldn't a single static suffice?
> Single static would not work because the code is parallel so it'll
> stomp over each other.
Sure, but would that matter in practice?
net_ratelimit() has similar parallelization and it doesn't
seem to matter there.
> or do you mean to have a common
> structure for every callsite (but instantiated separately)?
That might help a tiny bit.
Some possibly unnecessary bits:
o .msg_cdls
o __FILE__, __func__ and __LINE__ fields have marginal value
o .msg_subsys seems set only to DEBUG_SUBSYSTEM.
> This used to be a local structure in the past, but that
> caused considerable stack growth for some functions, that added
> up along the call chain, and that was the solution we came up with
> that did help.
next prev parent reply other threads:[~2016-03-12 18:56 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-12 18:00 [lustre-devel] [PATCH 0/6] Last batch of lnet selftest cleanup James Simmons
2016-03-12 18:00 ` James Simmons
2016-03-12 18:00 ` [lustre-devel] [PATCH 1/6] staging: lustre: Correct missing newline for CERROR call in sfw_handle_server_rpc James Simmons
2016-03-12 18:00 ` James Simmons
2016-03-12 18:23 ` [lustre-devel] " Joe Perches
2016-03-12 18:23 ` Joe Perches
2016-03-12 18:32 ` [lustre-devel] " Drokin, Oleg
2016-03-12 18:32 ` Drokin, Oleg
2016-03-12 18:56 ` Joe Perches [this message]
2016-03-12 18:56 ` Joe Perches
2016-03-12 19:17 ` [lustre-devel] " Drokin, Oleg
2016-03-12 19:17 ` Drokin, Oleg
2016-03-12 19:29 ` [lustre-devel] " Joe Perches
2016-03-12 19:29 ` Joe Perches
2016-03-12 18:00 ` [lustre-devel] [PATCH 2/6] staging: lustre: add missing buffer overflow fix for console.c James Simmons
2016-03-12 18:00 ` James Simmons
2016-03-12 18:00 ` [lustre-devel] [PATCH 3/6] staging: lustre: handle error returned from wait_event_timeout seltest timer James Simmons
2016-03-12 18:00 ` James Simmons
2016-03-12 18:00 ` [lustre-devel] [PATCH 4/6] staging: lustre: remove excess blank lines in lnet selftest code James Simmons
2016-03-12 18:00 ` James Simmons
2016-03-12 18:00 ` [lustre-devel] [PATCH 5/6] staging: lustre: realign some code in lnet selftest so its readable James Simmons
2016-03-12 18:00 ` James Simmons
2016-03-12 18:00 ` [lustre-devel] [PATCH 6/6] staging: lustre: cleanup comment style for lnet selftest James Simmons
2016-03-12 18:00 ` James Simmons
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=1457808989.11972.22.camel@perches.com \
--to=joe@perches.com \
--cc=andreas.dilger@intel.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=james.a.nunez@intel.com \
--cc=jsimmons@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lustre-devel@lists.lustre.org \
--cc=oleg.drokin@intel.com \
/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.