This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: Kprobes stress test prototype
- From: Masami Hiramatsu <mhiramat at redhat dot com>
- To: ananth at in dot ibm dot com
- Cc: systemtap-ml <systemtap at sources dot redhat dot com>, "Frank Ch. Eigler" <fche at redhat dot com>
- Date: Mon, 29 Jun 2009 19:09:02 -0400
- Subject: Re: Kprobes stress test prototype
- References: <4A451460.2040206@redhat.com> <20090629044953.GA5396@in.ibm.com>
Ananth N Mavinakayanahalli wrote:
> On Fri, Jun 26, 2009 at 02:33:04PM -0400, Masami Hiramatsu wrote:
>> Hi,
>>
>> Here is a script of kprobes stress test which uses
>> kprobes-ftrace engine. Currently, this doesn't use any
>> benchmarks for making a load.
>> Any updates, comments, and reports are welcome!
>>
>> On KVM/x86-64, I've found some symbols must be marked
>> as __kprobes or blacklisted by using this script.
>>
>> <always system hang up>
>> p irq_return
>> p start_critical_timing
>> p time_hardirqs_off
>> p bad_address
>> p trace_hardirqs_off_thunk
>> p restore
>>
>> <not always, but potentially dangerous>
>> p start_critical_timings
>> p stop_critical_timing
>> p trace_hardirqs_on_thunk
>> p restore_norax
>>
>> (I've encountered other odd memory corruptions too.
>> However, I couldn't identify the reason, it might be a bug
>> in kprobes or kvm.)
>>
>> Basic usage is very simple.
>> Of course, this needs kprobes-ftrace engine patchset which
>> I posted to lkml (http://lkml.org/lkml/2009/6/1/461).
>>
>> 1. Make a working area and put the script;
>> $ mkdir stest/
>> $ cp kprobestest stest/
>>
>> 2. Run it.
>> $ cd stest/
>> $ ./kprobestest run
>>
>> 3. If kernel gets trouble, reboot it and run again.
>> $ cd stest/
>> $ ./kprobestest run
>>
>> 4. Repeat it, until all symbols are tested.
>
> Excellent!
>
>> First, the test lists up all symbols in ".text" section, except
>> ".text.kprobes"(*) and breaks it into sub-lists. Initially, each
>> sub-lists has 64 symbols and are stored into "gray" dir.
>> The test passes each sub-list to kprobes-ftrace engine and makes
>> a load(currently, just sleep 2secs).
>
> Wouldn't this be a very simplistic scenario? There could be cases where
> the probes inserted were never hit during the 2sec interval, but may
> potentially still be dangerous.
Yeah, right.
I think we can easily expand kprobes-ftrace engine not only for
tracing events, but also for making a statistics result. Then,
we can check whether each event has been hit via debugfs files.
Thanks,
--
Masami Hiramatsu
Software Engineer
Hitachi Computer Products (America), Inc.
Software Solutions Division
e-mail: mhiramat@redhat.com