system-tap support in Ubuntu kernel
Bryan Wu
bryan.wu at canonical.com
Tue Jun 29 03:15:58 UTC 2010
On 06/29/2010 12:32 AM, Chase Douglas wrote:
> On Sun, 2010-06-27 at 20:50 +0300, Amit Kucheria wrote:
>> On 10 Jun 25, Sebastien Jan wrote:
>>> Just a short query regarding kernel config.
>>> Some of our teams are regularly making performance tests and some monitoring and use system-tap for this task.
>>> The Ubuntu config already includes some flags enabling a basic system-tap support out of the box.
>>> However, for most of our system-tap based tests, an additional config flag has to be activated: CONFIG_BLK_DEV_IO_TRACE
>>> This flag activates several additional tracers into the kernel config (see below for detailed config impact).
>>>
>>> We are looking at if we shall include these additional flags in our default kernel images, or if we shall make special builds dedicated to system-tap usage (including this additional flag).
>>>
>>> The criterion behind this choice are:
>>> - kernel size: I checked - increase of a bit less than 5%
>>> - performances: I have no idea
>>>
>>> => So the questions are:
>>> 1) I know that the ubuntu kernel team makes reviews of the flags to integrate into the ubuntu kernel. Were these flags investigated, and was there a rational for not taking them?
>>
>> Yes they are reviewed at UDS. I think someone on the kernel team will know
>> the details about this specific decision, the mailing list is now cc'ed.
>> Chase and Andy have been looking at the tracing problem in general.
>
> I've been watching perf and ftrace for the Ubuntu kernel. I had
> questions about the usage of some config options, so I inquired
> upstream:
>
> http://lkml.org/lkml/2010/5/25/382
>
>>> 2) Would you take these flags into the ti-omap4 branch of the maverick tree?
>>
>> I am curious to know if there is something in systemtap that cannot be
>> measured using ftrace? As I understand the winds blowing in kernel-land,
>> ftrace is the new favourite amongst all the tracing subsystems and is already
>> upstream.
>>
>> From personal experience, systemtap has always been very cumbersome to use,
>> ftrace is a lot easier. Also, the runtime overhead of ftrace is close to zero (really
>> zero?) when it is not enabled.
>
> The problem here is that ARM still cannot dynamically enable and disable
> ftrace. Thus, enabling it for ARM has a performance hit.
>
Right, during Maverick cycle, we might not be able to enable ftrace for armel
and omap due to miss dynamic ftrace feature.
> The only thing I am aware of that systemtap has over ftrace and perf
> probe (new in maverick) is the ability to modify code execution (more
> than just printing values of variables and registers). However, my gut
> tells me this isn't used very often.
>
>>> Complete changes implied by activating the CONFIG_BLK_DEV_IO_TRACE flag:
CONFIG_BLK_DEV_IO_TRACE=y in our master branch
>>> -ENABLE_DEFAULT_TRACERS n
Not existed in master, either.
>>> BINARY_PRINTF n -> y
CONFIG_BINARY_PRINTF=y in master
>>> BLK_DEV_IO_TRACE n -> y
ditto.
>>> +CONTEXT_SWITCH_TRACER y
ditto.
>>> +EVENT_TRACING y
ditto.
>>> +FTRACE_STARTUP_TEST n
Not set in master
>>> +GENERIC_TRACER y
CONFIG_GENERIC_TRACER=y in master
>>> +NET_DROP_MONITOR n
Not set in master
>>> +NOP_TRACER y
CONFIG_NOP_TRACER=y in master
>>> +STACKTRACE y
CONFIG_STACKTRACE=y in master
>>> +TRACEPOINTS y
CONFIG_TRACEPOINTS=y in master
>>> +TRACING y
CONFIG_TRACING=y in master
>
> See the following email for what's enabled in our common builds:
>
> http://lkml.org/lkml/2010/6/8/319
>
> We then have architecture and flavour overrides, so it's best to check
> our git tree for all the relevant config options.
>
After review these config options in master, I think it's OK for us to enable
CONFIG_BLK_DEV_IO_TRACE=y. All of these config options will be the same as
master branch config.
So Sebastien, please set them as you proposed here.
Thanks,
--
Bryan Wu <bryan.wu at canonical.com>
Kernel Developer +86.138-1617-6545 Mobile
Ubuntu Kernel Team | Hardware Enablement Team
Canonical Ltd. www.canonical.com
Ubuntu - Linux for human beings | www.ubuntu.com
More information about the kernel-team
mailing list