Enhancements to block IO & IO scheduler tapset

[Prerna Saxena]

Hi,

Reworked the patch per suggestions..

On 10/16/2009 08:56 PM, Frank Ch. Eigler wrote:
> Prerna Saxena<prerna@linux.vnet.ibm.com>  writes:
>
>> Here is a patch to add tracepoint-based probes to block IO and IO
>> scheduler tapsets.
>
> Thank you.
>
>> I had to add new probe aliases instead of adding fallbacks to
>> existing probes because the tracepoint that flags an event, say ,
>> elv_add_request, is not defined at function entry but somewhere in
>> the interior. [...]
>
> We don't have to have an exact match.  Likely a function-entry or
> function-return probe would do, filtered with predicates that skip
> inapplicable calls.
>
> For example, your elv_add_request = kernel.trace("block_rq_insert")
> seems to match recent kernel.function("elv_insert").

I reworked this probe to have kprobe based fallback. Unfortunately, this 
was the only place where it was feasible.

> trace("block_rq_abort") ~= kernel.function("blk_start_request"),
> perhaps with some filtering (cmd_flags | REQ_QUIET?).
>

In this case, a kprobe based fallback is not feasible because the same 
function is called from multiple places, and a tracepoint is placed just 
before a singular instance of this call. So a kprobe based probe in this 
place will generate far more number of calls than the tracepoint hit.
Its a similar situation for most other tracepoint based probes -- it is 
unfortunate that most probes cannot have kprobe fallbacks.

>
>> Also, the handlers for a lot of probe aliases are duplicated -- they
>> essentially expose the same set of local variables available in the
>> probe. Is there some way I could reduce duplication here ? [...]
>
>> probe ioscheduler_trace.plug = kernel.trace("block_plug"),
>> probe ioscheduler_trace.unplug_io = kernel.trace("block_unplug_io")
>> {
>> ..do something..
>> }
>
> We don't have a general preprocessor for such stuff.  Among the
> possibilities:
>
> - extending our own little preprocessor
>    - so something like %( foo = token token token %) to define,
>      %( foo %) to use
>
> - running cpp
>    - but that's bad because it'd mess up embedded-C code like #includes/#ifdefs
>
> - running m4
>    - possible; could run m4 on tapset/**/*.stp.m4 at systemtap build time
>      or at run time
>    - could make contextual script errors tricky
>    - would not mess with embedded-C
>    - m4_define(`foo',`token token token') to define,
>      foo   to use
>    - could export CONFIG_*, kernel_v, etc. variables for m4 conditionals
>
> - doing nothing
>    - so cut&  paste as today
>

I've just replicated handlers for now !

>
> - FChE

I've added testcases and man page updates. Looking fwd to feedback..

Regards,
-- 
Prerna Saxena

Linux Technology Centre,
IBM Systems and Technology Lab,
Bangalore, India
-------------- next part --------------
A non-text attachment was scrubbed...
Name: blockio-tracepoint.patch
Type: text/x-diff
Size: 16961 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/systemtap/attachments/20091118/aa77a63e/attachment.bin>