From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752921AbbH0LM2 (ORCPT ); Thu, 27 Aug 2015 07:12:28 -0400 Received: from mga03.intel.com ([134.134.136.65]:49846 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752027AbbH0LM0 (ORCPT ); Thu, 27 Aug 2015 07:12:26 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.17,422,1437462000"; d="scan'208";a="549503237" From: Alexander Shishkin To: Ingo Molnar Cc: Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, adrian.hunter@intel.com, Arnaldo Carvalho de Melo , Vince Weaver , Stephane Eranian Subject: Re: [PATCH RFC v1 0/4] perf: Introduce extended syscall error reporting In-Reply-To: <20150825084828.GA21511@gmail.com> References: <1437738359-23920-1-git-send-email-alexander.shishkin@linux.intel.com> <20150805170100.GP19282@twins.programming.kicks-ass.net> <20150822135101.GA7688@gmail.com> <877fokiyke.fsf@ashishki-desk.ger.corp.intel.com> <20150825084828.GA21511@gmail.com> User-Agent: Notmuch/0.20.2 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Thu, 27 Aug 2015 14:12:23 +0300 Message-ID: <87oahtgf3c.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Ingo Molnar writes: > * Alexander Shishkin wrote: > >> Ingo Molnar writes: >> >> > * Peter Zijlstra wrote: >> > >> >> On Fri, Jul 24, 2015 at 02:45:55PM +0300, Alexander Shishkin wrote: >> >> > Hi Peter and Ingo and everybody, >> >> > >> >> > Here's my second stab at improving perf's error reporting by attaching >> >> > arbitrary strings to the integer error codes. This is largely based >> >> > off of the previous email thread [1]. >> >> > >> >> > This time around, I employed a linker trick to convert the structures >> >> > containing extended error information into integers, which are then >> >> > made to look just like normal error codes so that IS_ERR_VALUE() and >> >> > friends would still work correctly on them. So no extra pointers in >> >> > the struct perf_event or anywhere else; the extended error codes are >> >> > passed around like normal error codes. They only need to be converted >> >> > in syscalls' topmost return statements. This is done in 1/4. >> >> > >> >> > Then, 2/4 illustrates how error sites can be extended to include more >> >> > information such as file names and line numbers [1]. >> >> > >> >> > The other two patches add perf_err() annotation to a few semi-randomly >> >> > picked places in perf core (3/4) and x86 bits (4/4). >> >> >> >> Looks generally ok to me. Thanks for doing this. >> > >> > I like this too. >> > >> > Alexander, mind sending a finalized, signed off version? >> >> Sure, I have everything ready, except for what about 2/4 (using >> CONFIG_DEBUG_KERNEL to extend output with file name and line number)? Should I >> leave it out or can we pick a more specific kconfig option or add a new one? > > I'd make it unconditional. We'll see whether we compress the debug info some more > if the number of callsites increases dramatically. Tooling can decide whether it > wants to display it by default, or print it only if some verbosity option is > activated. Done. > Also, mind structuring it in a bit more generic way that makes it possible for > other kernel subsystems to use this facility too? I.e. add a new header for it > instead of embedding it in perf, etc. Nothing complex, just some common-sense > generalization for a useful looking facility. Yes, now I have both a perf specific and a more generic implementation that perf then makes use of. Now let's arrive at a common denominator in the other thread, I guess, and then we can go ahead with either version. > For example the scheduler could start using it in struct sched_attr and feed back > the 15+ of failure causes in sys_sched_setattr() / __sched_setscheduler() in a bit > more usable fashion. Yes, what I posted yesterday should be useful for this case as well. Regards, -- Alex