On Thu, May 28, 2015 at 11:38 AM, Jovi Zhangwei wrote:
> Hi Mel,
>
> On Thu, May 28, 2015 at 5:00 AM, Mel Gorman wrote:
>> On Wed, May 27, 2015 at 11:05:33AM -0700, Jovi Zhangwei wrote:
>>> Hi,
>>>
>>> I got below kernel bug error in our 3.18.13 stab
On Thu, May 28, 2015 at 11:38 AM, Jovi Zhangwei j...@cloudflare.com wrote:
Hi Mel,
On Thu, May 28, 2015 at 5:00 AM, Mel Gorman mgor...@suse.de wrote:
On Wed, May 27, 2015 at 11:05:33AM -0700, Jovi Zhangwei wrote:
Hi,
I got below kernel bug error in our 3.18.13 stable kernel.
kernel BUG
Hi Mel,
On Thu, May 28, 2015 at 5:00 AM, Mel Gorman wrote:
> On Wed, May 27, 2015 at 11:05:33AM -0700, Jovi Zhangwei wrote:
>> Hi,
>>
>> I got below kernel bug error in our 3.18.13 stable kernel.
>> "kernel BUG at mm/migrate.c:1661!"
>&g
Hi Mel,
On Thu, May 28, 2015 at 5:00 AM, Mel Gorman mgor...@suse.de wrote:
On Wed, May 27, 2015 at 11:05:33AM -0700, Jovi Zhangwei wrote:
Hi,
I got below kernel bug error in our 3.18.13 stable kernel.
kernel BUG at mm/migrate.c:1661!
Source code:
1657static int
On Wed, May 27, 2015 at 11:05 AM, Jovi Zhangwei wrote:
> Hi,
>
> I got below kernel bug error in our 3.18.13 stable kernel.
> "kernel BUG at mm/migrate.c:1661!"
>
> Source code:
>
> 1657static int numamigrate_isolate_page(pg_data_t *pgdat, struc
Hi,
I got below kernel bug error in our 3.18.13 stable kernel.
"kernel BUG at mm/migrate.c:1661!"
Source code:
1657static int numamigrate_isolate_page(pg_data_t *pgdat, struct page *page)
1658 {
1659int page_lru;
1660
1661 VM_BUG_ON_PAGE(compound_order(page) &&
Hi,
I got below kernel bug error in our 3.18.13 stable kernel.
kernel BUG at mm/migrate.c:1661!
Source code:
1657static int numamigrate_isolate_page(pg_data_t *pgdat, struct page *page)
1658 {
1659int page_lru;
1660
1661 VM_BUG_ON_PAGE(compound_order(page)
On Wed, May 27, 2015 at 11:05 AM, Jovi Zhangwei j...@cloudflare.com wrote:
Hi,
I got below kernel bug error in our 3.18.13 stable kernel.
kernel BUG at mm/migrate.c:1661!
Source code:
1657static int numamigrate_isolate_page(pg_data_t *pgdat, struct page
*page)
1658 {
1659
Hi,
I got below kernel bug error in our 3.18.13 stable kernel.
"kernel BUG at mm/migrate.c:1661!"
Source code:
1657static int numamigrate_isolate_page(pg_data_t *pgdat, struct page *page)
1658 {
1659int page_lru;
1660
1661 VM_BUG_ON_PAGE(compound_order(page) &&
Hi,
I got below kernel bug error in our 3.18.13 stable kernel.
kernel BUG at mm/migrate.c:1661!
Source code:
1657static int numamigrate_isolate_page(pg_data_t *pgdat, struct page *page)
1658 {
1659int page_lru;
1660
1661 VM_BUG_ON_PAGE(compound_order(page)
On Wed, Mar 25, 2015 at 12:49 PM, Alexei Starovoitov wrote:
> tracex1_kern.c - C program compiled into BPF.
> It attaches to kprobe:netif_receive_skb
> When skb->dev->name == "lo", it prints sample debug message into trace_pipe
> via bpf_trace_printk() helper function.
>
> tracex1_user.c -
On Wed, Mar 25, 2015 at 12:49 PM, Alexei Starovoitov a...@plumgrid.com wrote:
tracex1_kern.c - C program compiled into BPF.
It attaches to kprobe:netif_receive_skb
When skb-dev-name == lo, it prints sample debug message into trace_pipe
via bpf_trace_printk() helper function.
tracex1_user.c -
On Tue, Jul 8, 2014 at 4:05 AM, Peter Zijlstra wrote:
> On Mon, Jul 07, 2014 at 09:55:43AM -0400, Sasha Levin wrote:
>> I've also had this one, which looks similar:
>>
>> [10375.005884] BUG: spinlock recursion on CPU#0, modprobe/10965
>> [10375.006573] lock: 0x8803a0fd7740, .magic: dead4ead,
On Tue, Jul 8, 2014 at 4:05 AM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, Jul 07, 2014 at 09:55:43AM -0400, Sasha Levin wrote:
I've also had this one, which looks similar:
[10375.005884] BUG: spinlock recursion on CPU#0, modprobe/10965
[10375.006573] lock: 0x8803a0fd7740,
On Fri, Apr 4, 2014 at 3:36 PM, Ingo Molnar wrote:
>
> * Jovi Zhangwei wrote:
>
>> I don't see any suggestion about integrating BPF before this review
>> cycle.
>
> Hm, I mentioned it at the kernel summit to folks who raised the ktap
> subject, but apparently not ov
On Fri, Apr 4, 2014 at 3:36 PM, Ingo Molnar mi...@kernel.org wrote:
* Jovi Zhangwei jovi.zhang...@gmail.com wrote:
I don't see any suggestion about integrating BPF before this review
cycle.
Hm, I mentioned it at the kernel summit to folks who raised the ktap
subject, but apparently
On Sun, Apr 6, 2014 at 1:22 AM, Alexei Starovoitov wrote:
> On Sat, Apr 5, 2014 at 7:23 AM, Jovi Zhangwei wrote:
>> On Sat, Apr 5, 2014 at 1:28 AM, Alexei Starovoitov wrote:
>>>
>>> 'ktap syntax' from user space point of view, can use ibpf as-is.
>>> Show m
On Sat, Apr 5, 2014 at 1:28 AM, Alexei Starovoitov wrote:
> On Fri, Apr 4, 2014 at 7:20 AM, Andi Kleen wrote:
>
>> BTW I agree that EBPF won't work for ktap. The models
>> (static vs dynamic typing etc.) are just too different.
>
> If you meant 'static vs dynamic safety checking' then yes.
>
On Sat, Apr 5, 2014 at 1:28 AM, Alexei Starovoitov a...@plumgrid.com wrote:
On Fri, Apr 4, 2014 at 7:20 AM, Andi Kleen a...@firstfloor.org wrote:
BTW I agree that EBPF won't work for ktap. The models
(static vs dynamic typing etc.) are just too different.
If you meant 'static vs dynamic
On Sun, Apr 6, 2014 at 1:22 AM, Alexei Starovoitov a...@plumgrid.com wrote:
On Sat, Apr 5, 2014 at 7:23 AM, Jovi Zhangwei jovi.zhang...@gmail.com wrote:
On Sat, Apr 5, 2014 at 1:28 AM, Alexei Starovoitov a...@plumgrid.com wrote:
'ktap syntax' from user space point of view, can use ibpf
On Fri, Apr 4, 2014 at 3:48 PM, Ingo Molnar wrote:
>
> * Jovi Zhangwei wrote:
>
>> On Fri, Apr 4, 2014 at 2:26 PM, Alexei Starovoitov wrote:
>> > On Thu, Apr 3, 2014 at 6:21 PM, Jovi Zhangwei
>> > wrote:
>> >> Hi Alexei,
>> >>
>>
On Fri, Apr 4, 2014 at 2:26 PM, Alexei Starovoitov wrote:
> On Thu, Apr 3, 2014 at 6:21 PM, Jovi Zhangwei wrote:
>> Hi Alexei,
>>
>> We talked a lot on ktap and ebpf integration in these days,
>> Now I think we can put into deeply to thinking out some
>> technic
On Fri, Apr 4, 2014 at 2:26 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On Thu, Apr 3, 2014 at 6:21 PM, Jovi Zhangwei jovi.zhang...@gmail.com wrote:
Hi Alexei,
We talked a lot on ktap and ebpf integration in these days,
Now I think we can put into deeply to thinking out some
technical
On Fri, Apr 4, 2014 at 3:48 PM, Ingo Molnar mi...@kernel.org wrote:
* Jovi Zhangwei jovi.zhang...@gmail.com wrote:
On Fri, Apr 4, 2014 at 2:26 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On Thu, Apr 3, 2014 at 6:21 PM, Jovi Zhangwei jovi.zhang...@gmail.com
wrote:
Hi Alexei,
We
Hi Alexei,
We talked a lot on ktap and ebpf integration in these days,
Now I think we can put into deeply to thinking out some
technical issues in there.
Firstly, I want to make sure you are support this ktap and
ebpf integration direction, I aware you have ongoing 'bpf filter'
patch set work,
Hi Alexei,
We talked a lot on ktap and ebpf integration in these days,
Now I think we can put into deeply to thinking out some
technical issues in there.
Firstly, I want to make sure you are support this ktap and
ebpf integration direction, I aware you have ongoing 'bpf filter'
patch set work,
On Wed, Apr 2, 2014 at 3:43 PM, Ingo Molnar wrote:
>
> * Jovi Zhangwei wrote:
>
>> So based on all these input, I suggest:
>>
>> Put all these community efforts together, figure out the proper
>> design implementation of dynamic tracing tool, ktap can be a good
On Wed, Apr 2, 2014 at 12:57 PM, Alexei Starovoitov wrote:
> On Mon, Mar 31, 2014 at 9:47 PM, Jovi Zhangwei
> wrote:
>> Hi Alexei,
>>
>> On Tue, Apr 1, 2014 at 5:29 AM, Alexei Starovoitov wrote:
>>> On Mon, Mar 31, 2014 at 3:01 AM, Jovi Zhangwei
>>>
On Wed, Apr 2, 2014 at 12:57 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On Mon, Mar 31, 2014 at 9:47 PM, Jovi Zhangwei jovi.zhang...@gmail.com
wrote:
Hi Alexei,
On Tue, Apr 1, 2014 at 5:29 AM, Alexei Starovoitov a...@plumgrid.com wrote:
On Mon, Mar 31, 2014 at 3:01 AM, Jovi Zhangwei
On Wed, Apr 2, 2014 at 3:43 PM, Ingo Molnar mi...@kernel.org wrote:
* Jovi Zhangwei jovi.zhang...@gmail.com wrote:
So based on all these input, I suggest:
Put all these community efforts together, figure out the proper
design implementation of dynamic tracing tool, ktap can be a good
start
On Mon, Mar 31, 2014 at 9:13 PM, Andi Kleen wrote:
> On Mon, Mar 31, 2014 at 10:01:04AM +0800, Jovi Zhangwei wrote:
>> On Sun, Mar 30, 2014 at 8:58 AM, Andi Kleen wrote:
>> >> Maybe in future, after ktap support "include" or "require" to
>&
On Tue, Apr 1, 2014 at 2:59 PM, Masami Hiramatsu
wrote:
> (2014/03/31 19:14), Jovi Zhangwei wrote:
>> On Mon, Mar 31, 2014 at 5:10 PM, Masami Hiramatsu
>> wrote:
>>> (2014/03/28 22:47), Jovi Zhangwei wrote:
>>>> kp_events.c handle ktap events management(reg
On Tue, Apr 1, 2014 at 2:59 PM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2014/03/31 19:14), Jovi Zhangwei wrote:
On Mon, Mar 31, 2014 at 5:10 PM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2014/03/28 22:47), Jovi Zhangwei wrote:
kp_events.c handle ktap events
On Mon, Mar 31, 2014 at 9:13 PM, Andi Kleen a...@firstfloor.org wrote:
On Mon, Mar 31, 2014 at 10:01:04AM +0800, Jovi Zhangwei wrote:
On Sun, Mar 30, 2014 at 8:58 AM, Andi Kleen a...@firstfloor.org wrote:
Maybe in future, after ktap support include or require to
import user defined library
Hi Alexei,
On Tue, Apr 1, 2014 at 5:29 AM, Alexei Starovoitov wrote:
> On Mon, Mar 31, 2014 at 3:01 AM, Jovi Zhangwei
> wrote:
>> Hi Ingo,
>>
>> On Mon, Mar 31, 2014 at 3:17 PM, Ingo Molnar wrote:
>>>
>>> * Jovi Zhangwei wrote:
>>>
>>&
On Mon, Mar 31, 2014 at 5:10 PM, Masami Hiramatsu
wrote:
> (2014/03/28 22:47), Jovi Zhangwei wrote:
>> kp_events.c handle ktap events management(registry, destroy, event callback)
>>
>> This file is core event management interface between ktap and kernel.
>>
Hi Ingo,
On Mon, Mar 31, 2014 at 3:17 PM, Ingo Molnar wrote:
>
> * Jovi Zhangwei wrote:
>
>> Hi All,
>>
>> The following set of patches add ktap tracing tool.
>>
>> ktap is a new script-based dynamic tracing tool for Linux.
>> It uses a scri
Hi Ingo,
On Mon, Mar 31, 2014 at 3:17 PM, Ingo Molnar mi...@kernel.org wrote:
* Jovi Zhangwei jovi.zhang...@gmail.com wrote:
Hi All,
The following set of patches add ktap tracing tool.
ktap is a new script-based dynamic tracing tool for Linux.
It uses a scripting language and lets
On Mon, Mar 31, 2014 at 5:10 PM, Masami Hiramatsu
masami.hiramatsu...@hitachi.com wrote:
(2014/03/28 22:47), Jovi Zhangwei wrote:
kp_events.c handle ktap events management(registry, destroy, event callback)
This file is core event management interface between ktap and kernel.
Exposed
Hi Alexei,
On Tue, Apr 1, 2014 at 5:29 AM, Alexei Starovoitov a...@plumgrid.com wrote:
On Mon, Mar 31, 2014 at 3:01 AM, Jovi Zhangwei jovi.zhang...@gmail.com
wrote:
Hi Ingo,
On Mon, Mar 31, 2014 at 3:17 PM, Ingo Molnar mi...@kernel.org wrote:
* Jovi Zhangwei jovi.zhang...@gmail.com wrote
On Mon, Mar 31, 2014 at 10:17 AM, Li Zefan wrote:
> On 2014/3/28 22:45, Jovi Zhangwei wrote:
>> This compiles the ktapvm as one huge C file and allows
>> GCC to generate faster and shorter code.
>>
>> No amalgamation build in x86_64:
>> ktapvm.ko: 3.1M
&
On Mon, Mar 31, 2014 at 1:19 AM, Andi Kleen wrote:
>> See test/benchmark/cmp_table.sh, that script compare
>
> Is that a realistic tracing scenario?
>
Yes, it's quite common to use string key in dynamic tracing tool,
for example, See samples/userspace/glibc_func_hist.kp
var s = {}
trace
On Mon, Mar 31, 2014 at 1:17 AM, Andi Kleen wrote:
>> That's designed for portability initially, it means we can just run bytecode
>> without compile script file everywhere, especially when compilation is
>> a heavily task for some embedded platform, even though ktap compilation
>> is extremely
On Sun, Mar 30, 2014 at 8:58 AM, Andi Kleen wrote:
>> Maybe in future, after ktap support "include" or "require" to
>> import user defined library in userspace.
>
> Can't you just have some hardcoded standard script for now that is
> always appeneded and provides these functions?
>
Maybe it's
On Sun, Mar 30, 2014 at 11:50 AM, Andi Kleen wrote:
>
> It's not clear to me why a kernel script language needs
> all that complicated string interning code.
>
> What kind of scripts would create as many strings that
> it would be worth it?
>
> I think it would be better to replace it with a
On Sun, Mar 30, 2014 at 9:00 AM, Andi Kleen wrote:
>
> For now I would suggest concentrating on the kernel ring 0 parts only.
> Split the user space part into a separate patchkit that is posted
> on a separate schedule.
>
> It's hard to make progress with too large patchkits.
>
Agreed, we can
On Sun, Mar 30, 2014 at 11:56 AM, Andi Kleen wrote:
>> + * You should have received a copy of the GNU General Public License along
>> with
>> + * this program; if not, write to the Free Software Foundation, Inc.,
>> + * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
>
> We're not
On Sun, Mar 30, 2014 at 10:47 AM, Andi Kleen wrote:
>> +/* Read debug info of a prototype. */
>> +static void bcread_dbg(BCReadCtx *ctx, ktap_proto_t *pt, int sizedbg)
>> +{
>> + void *lineinfo = (void *)proto_lineinfo(pt);
>> +
>> + bcread_block(ctx, lineinfo, sizedbg);
>> + /* Swap
On Sun, Mar 30, 2014 at 11:58 AM, Andi Kleen wrote:
>>
>> A lot of code in this file is duplicated with kernel trace_output.c.
>
> Please modify trace_output instead to avoid this.
>
Yeah, ktap transport functionality is based on ftrace ring buffer,
and reading buffer is through trace pipe.
I
On Sun, Mar 30, 2014 at 1:04 AM, Greg Kroah-Hartman
wrote:
> On Sat, Mar 29, 2014 at 03:32:12PM +0800, Jovi Zhangwei wrote:
>> >> +struct syscall_metadata **syscalls_metadata;
>> >> +
>> >> +/*TODO: kill this function in future */
>> >>
On Sun, Mar 30, 2014 at 1:04 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
On Sat, Mar 29, 2014 at 03:32:12PM +0800, Jovi Zhangwei wrote:
+struct syscall_metadata **syscalls_metadata;
+
+/*TODO: kill this function in future */
+static int __init init_dummy_kernel_functions(void
On Sun, Mar 30, 2014 at 11:58 AM, Andi Kleen a...@firstfloor.org wrote:
A lot of code in this file is duplicated with kernel trace_output.c.
Please modify trace_output instead to avoid this.
Yeah, ktap transport functionality is based on ftrace ring buffer,
and reading buffer is through trace
On Sun, Mar 30, 2014 at 10:47 AM, Andi Kleen a...@firstfloor.org wrote:
+/* Read debug info of a prototype. */
+static void bcread_dbg(BCReadCtx *ctx, ktap_proto_t *pt, int sizedbg)
+{
+ void *lineinfo = (void *)proto_lineinfo(pt);
+
+ bcread_block(ctx, lineinfo, sizedbg);
+ /*
On Sun, Mar 30, 2014 at 11:56 AM, Andi Kleen a...@firstfloor.org wrote:
+ * You should have received a copy of the GNU General Public License along
with
+ * this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
We're
On Sun, Mar 30, 2014 at 9:00 AM, Andi Kleen a...@firstfloor.org wrote:
For now I would suggest concentrating on the kernel ring 0 parts only.
Split the user space part into a separate patchkit that is posted
on a separate schedule.
It's hard to make progress with too large patchkits.
On Sun, Mar 30, 2014 at 11:50 AM, Andi Kleen a...@firstfloor.org wrote:
It's not clear to me why a kernel script language needs
all that complicated string interning code.
What kind of scripts would create as many strings that
it would be worth it?
I think it would be better to replace it
On Sun, Mar 30, 2014 at 8:58 AM, Andi Kleen a...@firstfloor.org wrote:
Maybe in future, after ktap support include or require to
import user defined library in userspace.
Can't you just have some hardcoded standard script for now that is
always appeneded and provides these functions?
Maybe
On Mon, Mar 31, 2014 at 1:17 AM, Andi Kleen a...@firstfloor.org wrote:
That's designed for portability initially, it means we can just run bytecode
without compile script file everywhere, especially when compilation is
a heavily task for some embedded platform, even though ktap compilation
is
On Mon, Mar 31, 2014 at 1:19 AM, Andi Kleen a...@firstfloor.org wrote:
See test/benchmark/cmp_table.sh, that script compare
Is that a realistic tracing scenario?
Yes, it's quite common to use string key in dynamic tracing tool,
for example, See samples/userspace/glibc_func_hist.kp
var s =
On Mon, Mar 31, 2014 at 10:17 AM, Li Zefan lize...@huawei.com wrote:
On 2014/3/28 22:45, Jovi Zhangwei wrote:
This compiles the ktapvm as one huge C file and allows
GCC to generate faster and shorter code.
No amalgamation build in x86_64:
ktapvm.ko: 3.1M
amalgamation build in x86_64
Signed-off-by: Jovi Zhangwei
---
tools/ktap/README.md | 149 +++
1 file changed, 149 insertions(+)
create mode 100644 tools/ktap/README.md
diff --git a/tools/ktap/README.md b/tools/ktap/README.md
new file mode 100644
index 000..66dc2d1
-off-by: Jovi Zhangwei
---
tools/ktap/doc/tutorial.md | 666 +
1 file changed, 666 insertions(+)
create mode 100644 tools/ktap/doc/tutorial.md
diff --git a/tools/ktap/doc/tutorial.md b/tools/ktap/doc/tutorial.md
new file mode 100644
index 000
Simple arch related definition and error msg definition.
Signed-off-by: Jovi Zhangwei
---
include/uapi/ktap/ktap_arch.h | 33 ++
include/uapi/ktap/ktap_err.h| 11
include/uapi/ktap/ktap_errmsg.h | 135
3 files changed, 179 insertions
ime:
1). mainthread conetxt
mainthread context is the context in ktap thread.
2). probe context
ktap runtime pre-allocated percpu probe context.
9. ktap_global_state_t
global state of ktap runtime, it's access by G(ks).
Signed-off-by: Jovi Zhangwei
---
include/uapi/ktap/ktap_type
This file is use for uprobe(include SDT) symbol lookup,
for example:
trace probe:/lib64/libc.so.6:malloc {
print("malloc entry:", execname)
}
trace sdt:/lib64/libc.so.6:* {
print(execname, argstr)
}
It need libelf library support.
Signed-off-by: Jovi Zhangwei
---
ktap is based on laujit and lua, so carry they copyright notices
and MIT license in ktap tree.
Signed-off-by: Jovi Zhangwei
---
tools/ktap/COPYRIGHT | 63
1 file changed, 63 insertions(+)
create mode 100644 tools/ktap/COPYRIGHT
diff --git
To make ktap script looks more beautiful.
Signed-off-by: Jovi Zhangwei
---
tools/ktap/vim/ftdetect/ktap.vim | 3 ++
tools/ktap/vim/syntax/ktap.vim | 106 +++
2 files changed, 109 insertions(+)
create mode 100644 tools/ktap/vim/ftdetect/ktap.vim
create
This is ktap ring buffer consumer, a thread poll content from
'/sys/kernel/debug/ktap/trace_pipe_%pid' debugfs file.
Signed-off-by: Jovi Zhangwei
---
tools/ktap/kp_reader.c | 106 +
1 file changed, 106 insertions(+)
create mode 100644 tools/ktap
Bytecode writer and listing.
[root@localhost ktap]# ./ktap -b -e 'var s = {} s["key"] = 1'
-- BYTECODE -- (command line):0-1
0001TNEW0 0
0002KSHORT 1 1
0003TSETS 1 0 0 ; "key"
0004RET00 1
Signed-off-by: Jovi
tell the data in my box)
Signed-off-by: Jovi Zhangwei
---
tools/ktap/test/README | 69
tools/ktap/test/arithmetic.t | 109 ++
tools/ktap/test/benchmark/cmp_neq.sh | 158 +
tools/ktap/test/benchmark/cmp_profile.sh | 54 +++
tools/ktap/test
Signed-off-by: Jovi Zhangwei
---
tools/ktap/kp_util.c | 646 +++
tools/ktap/kp_util.h | 120 ++
2 files changed, 766 insertions(+)
create mode 100644 tools/ktap/kp_util.c
create mode 100644 tools/ktap/kp_util.h
diff --git a/tools/ktap
Makefile for userspace binary.
Signed-off-by: Jovi Zhangwei
---
tools/ktap/Makefile | 130
1 file changed, 130 insertions(+)
create mode 100644 tools/ktap/Makefile
diff --git a/tools/ktap/Makefile b/tools/ktap/Makefile
new file mode 100644
to tracing
Signed-off-by: Jovi Zhangwei
---
tools/ktap/kp_main.c | 443 +++
1 file changed, 443 insertions(+)
create mode 100644 tools/ktap/kp_main.c
diff --git a/tools/ktap/kp_main.c b/tools/ktap/kp_main.c
new file mode 100644
index 000
ktap_eventdesc_t structure, and finially
pass to 'kdebug.trace_by_id' function.
Signed-off-by: Jovi Zhangwei
---
tools/ktap/kp_parse_events.c | 798 +++
1 file changed, 798 insertions(+)
create mode 100644 tools/ktap/kp_parse_events.c
diff --git a/tools
Signed-off-by: Jovi Zhangwei
---
kernel/trace/ktap/Kconfig | 21 +
1 file changed, 21 insertions(+)
create mode 100644 kernel/trace/ktap/Kconfig
diff --git a/kernel/trace/ktap/Kconfig b/kernel/trace/ktap/Kconfig
new file mode 100644
index 000..21f8d2e
--- /dev/null
This Makefile compiles kernel module and generate ktapvm.ko.
Signed-off-by: Jovi Zhangwei
---
kernel/trace/ktap/Makefile | 50 ++
1 file changed, 50 insertions(+)
create mode 100644 kernel/trace/ktap/Makefile
diff --git a/kernel/trace/ktap/Makefile
differences)
Signed-off-by: Jovi Zhangwei
---
kernel/trace/ktap/amalg.c | 37 +
1 file changed, 37 insertions(+)
create mode 100644 kernel/trace/ktap/amalg.c
diff --git a/kernel/trace/ktap/amalg.c b/kernel/trace/ktap/amalg.c
new file mode 100644
index 000
tracing syntax, not perf backend tracing.
perf backend tracing have a long code path before reach ktap callback,
and it need to copy event buffer firstly.
Signed-off-by: Jovi Zhangwei
---
kernel/trace/ktap/kp_events.c | 832 ++
kernel/trace/ktap/kp_eve
object is linked in G(ks)->allgc.
6). kp_obj_kstack2str
convert kernel stack to string.
7). kp_obj_freeall
free all object, called in kp_vm_exit.
Signed-off-by: Jovi Zhangwei
---
kernel/trace/ktap/kp_obj.c | 281 +
kernel/trace/k
library(lib_net.c):
net.ip_sock_saddr
net.ip_sock_daddr
net.format_ip_addr
5). table library(lib_table.c):
table.new
6). timer library(lib_timer.c):
timer.profile
timer.tick
Signed-off-by: Jovi Zhangwei
---
kernel/trace/ktap/lib_ansi.c | 142 ++
kernel/trace/ktap/lib_base.c | 407
(stack())'
Signed-off-by: Jovi Zhangwei
---
kernel/trace/ktap/kp_transport.c | 649 +++
kernel/trace/ktap/kp_transport.h | 13 +
2 files changed, 662 insertions(+)
create mode 100644 kernel/trace/ktap/kp_transport.c
create mode 100644 kernel/trace/ktap
kp_vm_validate_code
kp_vm_call_proto
Signed-off-by: Jovi Zhangwei
---
kernel/trace/ktap/ktap.c | 255 +++
kernel/trace/ktap/ktap.h | 176
2 files changed, 431 insertions(+)
create mode 100644 kernel
execute loop related bytecode, to forbid
deadloop, it limit can be set by module parameter.
Signed-off-by: Jovi Zhangwei
---
kernel/trace/ktap/kp_vm.c | 1754 +
kernel/trace/ktap/kp_vm.h | 43 ++
2 files changed, 1797 insertions(+)
create mode 100644
Exposed function:
ktap_proto_t *kp_bcread(ktap_state_t *ks, unsigned char *buff, int len)
Function kp_bcread read bytecode from buff, and return
ktap top-level function prototype.
Signed-off-by: Jovi Zhangwei
---
kernel/trace/ktap/kp_bcread.c | 429
+ b/kernel/trace/ktap/kp_mempool.c
@@ -0,0 +1,94 @@
+/*
+ * kp_mempool.c - ktap memory pool, service for string allocation
+ *
+ * This file is part of ktap by Jovi Zhangwei.
+ *
+ * Copyright (C) 2012-2014 Jovi Zhangwei .
+ *
+ * ktap is free software; you can redistribute it and/or modify it
+ * un
on performance is better than systemtap, especially
for string key(because all string is interned in ktap).
Note table is not aggregation in Systemtap and Dtrace, aggregation
use percpu buffer. ktap will introduce aggregation soon with
Dtrace aggregation syntax.
Signed-off-by: Jovi Zhangwei
g this software in kernel tree is
to make it more possible to get feedback from users
and thus polish the code.
Thank you.
Signed-off-by: Jovi Zhangwei
Jovi Zhangwei (29):
ktap: add tools/ktap/README.md file
ktap: add ktap tutorial(tools/ktap/doc/tutorial.md)
ktap: add sample scripts(tool
, ITERL, IITERL, JITERL, LOOP, ILOOP, JLOOP, JMP
11). Function headers (All is not used in ktap)
FUNCF, IFUNCF, JFUNCF, FUNCV, JFUNCV, FUNCC, FUNCCW
12). ktap specific bytecodes
VARGN, VARGSTR, VPROBENAME, VPID, VTID, VUID, VCPU, VEXECNAME, GFUNC
Signed-off-by: Jovi Zhangwei
---
include/uapi/ktap
Hi,
On Sat, Mar 29, 2014 at 2:52 AM, Andi Kleen wrote:
> Jovi Zhangwei writes:
>
>> Use amalgamation build make ktapvm.ko much smaller.
>>
>> No amalgamation build in x86_64:
>> ktapvm.ko: 2.4M
>>
>> amalgamation build in x86_64:
>> ktapvm.ko
Hi Andi,
On Sat, Mar 29, 2014 at 2:38 AM, Andi Kleen wrote:
> Jovi Zhangwei writes:
>
> Quick review of the file.
>
>> +#include
>> +#if LINUX_VERSION_CODE < KERNEL_VERSION(3, 1, 0)
>> +#error "Currently ktap don't support kernel older than 3.1"
&g
Hi Andi,
On Sat, Mar 29, 2014 at 2:38 AM, Andi Kleen a...@firstfloor.org wrote:
Jovi Zhangwei jovi.zhang...@gmail.com writes:
Quick review of the file.
+#include linux/version.h
+#if LINUX_VERSION_CODE KERNEL_VERSION(3, 1, 0)
+#error Currently ktap don't support kernel older than 3.1
Hi,
On Sat, Mar 29, 2014 at 2:52 AM, Andi Kleen a...@firstfloor.org wrote:
Jovi Zhangwei jovi.zhang...@gmail.com writes:
Use amalgamation build make ktapvm.ko much smaller.
No amalgamation build in x86_64:
ktapvm.ko: 2.4M
amalgamation build in x86_64:
ktapvm.ko: 1.1M
User can set use
-off-by: Jovi Zhangwei jovi.zhang...@gmail.com
Jovi Zhangwei (29):
ktap: add tools/ktap/README.md file
ktap: add ktap tutorial(tools/ktap/doc/tutorial.md)
ktap: add sample scripts(tools/ktap/samples/*)
ktap: add basic ktap types definition(include/uapi/ktap/ktap_types.h)
ktap: add bytecode
, ITERL, IITERL, JITERL, LOOP, ILOOP, JLOOP, JMP
11). Function headers (All is not used in ktap)
FUNCF, IFUNCF, JFUNCF, FUNCV, JFUNCV, FUNCC, FUNCCW
12). ktap specific bytecodes
VARGN, VARGSTR, VPROBENAME, VPID, VTID, VUID, VCPU, VEXECNAME, GFUNC
Signed-off-by: Jovi Zhangwei jovi.zhang...@gmail.com
--- /dev/null
+++ b/kernel/trace/ktap/kp_mempool.c
@@ -0,0 +1,94 @@
+/*
+ * kp_mempool.c - ktap memory pool, service for string allocation
+ *
+ * This file is part of ktap by Jovi Zhangwei.
+ *
+ * Copyright (C) 2012-2014 Jovi Zhangwei jovi.zhang...@gmail.com.
+ *
+ * ktap is free software; you can
, especially
for string key(because all string is interned in ktap).
Note table is not aggregation in Systemtap and Dtrace, aggregation
use percpu buffer. ktap will introduce aggregation soon with
Dtrace aggregation syntax.
Signed-off-by: Jovi Zhangwei jovi.zhang...@gmail.com
---
kernel/trace/ktap
(stack())'
Signed-off-by: Jovi Zhangwei jovi.zhang...@gmail.com
---
kernel/trace/ktap/kp_transport.c | 649 +++
kernel/trace/ktap/kp_transport.h | 13 +
2 files changed, 662 insertions(+)
create mode 100644 kernel/trace/ktap/kp_transport.c
create mode 100644
kp_vm_validate_code
kp_vm_call_proto
Signed-off-by: Jovi Zhangwei jovi.zhang...@gmail.com
---
kernel/trace/ktap/ktap.c | 255 +++
kernel/trace/ktap/ktap.h | 176
2 files changed, 431 insertions
execute loop related bytecode, to forbid
deadloop, it limit can be set by module parameter.
Signed-off-by: Jovi Zhangwei jovi.zhang...@gmail.com
---
kernel/trace/ktap/kp_vm.c | 1754 +
kernel/trace/ktap/kp_vm.h | 43 ++
2 files changed, 1797 insertions
Exposed function:
ktap_proto_t *kp_bcread(ktap_state_t *ks, unsigned char *buff, int len)
Function kp_bcread read bytecode from buff, and return
ktap top-level function prototype.
Signed-off-by: Jovi Zhangwei jovi.zhang...@gmail.com
---
kernel/trace/ktap/kp_bcread.c | 429
1 - 100 of 228 matches
Mail list logo
