Message-ID: <1AE640813FDE7649BE1B193DEA596E881EF14695@SHSMSX101.ccr.corp.intel.com>
Date:	Mon, 27 Jul 2015 00:42:16 +0000
From:	"Zheng, Lv" <lv.zheng@...el.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
CC:	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"Brown, Len" <len.brown@...el.com>, Lv Zheng <zetalog@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: RE: [PATCH 0/4] ACPI: Update method tracing facility.

Hi, Rafael

> From: linux-acpi-owner@...r.kernel.org [mailto:linux-acpi-owner@...r.kernel.org] On Behalf Of Rafael J. Wysocki
> Sent: Saturday, July 25, 2015 3:56 AM
> 
> On Friday, July 24, 2015 02:02:33 AM Zheng, Lv wrote:
> > Hi, Rafael
> 
> Hi,
> 
> > ACPICA logs contain details (trace logs) that may be useful for development.
> > But the quantity of the trace logs are huge to be put into the kernel log buffer.
> > Originally, we have a "trace log reducer" in /sys/modules/acpi/parameter, it is the method tracing facility.
> > We can specify a method name, for example, "_PS0", and corresponding debug layer/level for the "trace log reducer".
> > When the AML interpreter starts to execute the method, the tracing debug level/layer will be applied.
> > When the AML interpreter stops to execute the method, the original debug level/layer is restored.
> > Thus the ACPICA trace logs can only be enabled during the period the specified method is executed and its output thus can be
> reduced.
> > The facility invokes acpi_debug_trace() to do the flexible settings.
> > See Documentation/acpi/method-tracing.txt for reference.
> >
> > Actually, the "trace log reducer" facility is buggy and some of the shortcomings put us into the trouble in using it.
> > 1. We cannot specify a full path for the tracing method. For example, though we only want to track \_SB,PCI0.I2C0._PS0, we can only
> specify "_PS0" and all _PS0 method execution logs will be dumped, the unwanted _PS0 execution trace logs may still blow the kernel
> log buffer up.
> > 2. We can only specify a method that is passed to acpi_evaluate_object(). For example, if \_SB.LID0._LID invokes
> \_SB.PCI0.LPCB.H_EC.ECRD, since Linux never passes \_SB.PCI0.LPCB.H_EC.ECRD to acpi_evaluate_object(), specifying "ECRD" cannot
> match the start of the execution to enable the "trace log reducer".
> >
> > So during this ACPICA release, we re-implement the facility in the ACPICA dispatcher rather than implementing it in
> acpi_evaluate_object and allows the full path to be specified to precisely lock on a specific control method.
> > It is achieved by doing the following improvements:
> > 1. Re-implements the facility in the ACPICA dispatcher component.
> > 1. Introduce a new AML path -> ASL path decoding facility to zap the trailing underscore. Originally ACPICA decodes AML path into
> such a format that the user must explicitly specify the trailing. And users are likely to forget to put the underscores and leave us with
> useless trace logs.
> > 2. Move the exception stack walker from the ACPICA debugger component to the ACPICA dispatcher component. When an
> exception is encountered, AML interpreter just jumps to the top of the stack. Thus we need a facility to walk the stack so that the
> method can be matched to implement the "end of the tracing".
> >
> > And with the improvements, we now can do an exciting tracing:
> > 1. When the trace is enabled, we add new log entries for the begin/end of each control method that is executed by the interpreter.
> > 2. When the trace is enabled, we add new log entries for the begin/end of each opcode that is executed by the interpreter.
> > 3. We allow the method virtual address and the opcode virtual address to be dumped along with the begin/end logs.
> > This makes it possible to draw a AML call graph using the dumped log and we can calculate the execution time of a control
> method/opcode.
> > We can use it either for performance tuning or remote debugging.
> > The new feature is known as "AML execution tracer".
> >
> > All of above improvements are done to the acpi_debug_trace(), new features/parameters are added to this ACPICA interface.
> > Now acpi_debug_trace() can be used not only as the "trace log reducer" but also the "AML execution tracer".
> > As its user, /sys/modules/acpi/parameters/trace_xxx files need to be updated so that we can use the fixed/improved old feature
> and the new feature in the Linux kernel.
> >
> > There is an user experience example of the new feature (AML execution tracer) on the kernel Bugzilla:
> > https://bugzilla.kernel.org/show_bug.cgi?id=70891
> > The user reported a delay to the ACPICA developers mailing list and I helped to file a bug there.
> > With the assistance of this debugging facility (see comment 29, 30, 31), I found the delay was caused by the EC driver (so this is really
> an effective debugging facility).
> > This bug (erroneously reported as an ACPICA issue) motivated me to look at the Linux EC driver and offered the fixes to help to
> improve the quality of the EC/GPE implementations.
> >
> > Hope this explanation can help.
> 
> All of that is good information, so what about sending a documentation patch
> with it?

OK, I'll re-send this patchset to include the above information in Documentation/acpi/method-tracing.txt.

Thanks and best regards
-Lv

> 
> Rafael
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists