Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753426AbcCLSdE (ORCPT ); Sat, 12 Mar 2016 13:33:04 -0500 Received: from mga04.intel.com ([192.55.52.120]:3318 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751626AbcCLScz convert rfc822-to-8bit (ORCPT ); Sat, 12 Mar 2016 13:32:55 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,326,1455004800"; d="scan'208";a="668323254" From: "Drokin, Oleg" To: Joe Perches CC: James Simmons , Greg Kroah-Hartman , "" , "Dilger, Andreas" , Linux Kernel Mailing List , "Lustre Development List" , "Nunez, James A" Subject: Re: [PATCH 1/6] staging: lustre: Correct missing newline for CERROR call in sfw_handle_server_rpc Thread-Topic: [PATCH 1/6] staging: lustre: Correct missing newline for CERROR call in sfw_handle_server_rpc Thread-Index: AQHRfIkcu098f4cr7Uia1SPG83ikN59WpZKAgAACpYA= Date: Sat, 12 Mar 2016 18:32:53 +0000 Message-ID: <5A0A38B8-B387-436D-B72A-7D8247B6A00D@intel.com> References: <1457805636-23859-1-git-send-email-jsimmons@infradead.org> <1457805636-23859-2-git-send-email-jsimmons@infradead.org> <1457807005.11972.9.camel@perches.com> In-Reply-To: <1457807005.11972.9.camel@perches.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.254.1.152] Content-Type: text/plain; charset=US-ASCII Content-ID: Content-Transfer-Encoding: 7BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1240 Lines: 34 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 >> >> 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. or do you mean to have a common structure for every callsite (but instantiated separately)? 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.