系统技术非业余研究

在做系统调优或者调查性能问题的的时候，比如说调查一个锁的性能问题。 这把锁的代码会有很多路径会调用， 我们可以在锁的地方设个probe点，但是我们无法知道那个路径是最经常调用的。 所以我就写了个stap脚本来解决这个问题，代码在RHEL 5.4/6下都调试没有问题的。

$ cat  > dig.stp 
global stacks_count

probe process(@1).function(@2)
{
 stacks_count[ubacktrace()]++;
}

function sprint_stackx(stack)
{
addr = tokenize(stack, " ");
while(addr != "")
{
        fun= symname(strtol(addr, 16));
        s = fun . "->" . s;
        addr = tokenize("", " ");
}
return s;
}

function print_top_stack () {
  printf ("%50s %10s\n", "STACK", "COUNT")
  foreach (stack in stacks_count- limit 20) {
    printf("%50s %10d\n", sprint_stackx(stack), stacks_count[stack])
  }
  delete stacks_count
}

probe timer.s(5) {
  print_top_stack ()
  printf("--------------------------------------------------------------\n")
}

CTRL+D

#我们用nmon这个程序来试验下吧
#脚本的使用方法是: stap dig.stp prog funcs
#注意这个程序需要-g编译， 才能有符号信息

#在另外一个控制台下运行nmon, 打开磁盘，CPU监控等。
$nmon

$ sudo stap dig.stp nmon proc_*
                                             STACK      COUNT
                                 main->proc_read->          2
                                  main->proc_cpu->          2
                                 main->proc_read->          2
                                  main->proc_mem->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
                 main->proc_mem->proc_mem_search->          2
--------------------------------------------------------------
...

哈效果不错哦！

祝玩的开心。

通常我们在做内核编程的时候，会用到内核的数据结构，比如说textsearch提供了几种算法用于支付串查找。在用于正式的项目前，我们会希望考察下他的用法以及想体验下。最通常的做法是自己写个module,写个makefile,编译，运行，然后去dmesg里面看printk的结果。这个过程没啥问题，就是太罗嗦。好了，现在我们有更方便的方法了：systemtap.

Systemtap是个脚本，先翻译成c kernel模块代码，然后编译，插入到内核运行，同时提供最基本的内核和应用模块的通讯管道，在应用模块这里收集信息。 它还支持guru模式，让用户直接插入c代码。 这样我们就可以利用stap的这一特性来做我们的实验。
Read more…

参考文章：
1. https://groups.google.com/group/erlang-programming/msg/2d61b1083a10a7b6

2. http://erlang.2086793.n4.nabble.com/How-to-Cross-compile-Erlang-OTP-R13B04-for-TileraPro64-td2119304.html

美国Tilera公司的众核服务器，单颗内核包含64颗CPU。硬件架构图：

卡长这样的：

Erlang已经可以在这款CPU上成功运行，我们可以参考Ulf Wiger在Multicore ☺ Message-passing Concurrency 文档中关于Erlang在Tilera上的性能图.

Erlang系统前2年就开始正式支持Tilera，一直用这个CPU来调整他的调度器，所以性能和基础的编译运行支持都很到位。

Linux内核2.6.36起就开始支持Tilera的CPU架构了，看起来前途不错。

最近 上海泛腾电子科技 开始在国内销售 Tilera机器， 我公司也得到一台样机，使得我有机会把玩下这个高科技！

该测试机是PCI-e的形式，是单板机，直接安装在PC机或者是服务器里,好处是可以通过主机的VGA口接显示器直接调试。当然也可以作为智能网卡来使用。构成一个与Host的异构结构，通过PCI-e总线进行通讯。

还需要相应的配套SDK: 目前有TileraMDE-2.1.2.112814 和 TileraMDE-3.0.alpha3.116173 二个版本, 来负责和板卡的通信。 推荐用2.0的，好像不容易出问题。

废话少说，让我们开始享受64核心快乐旅程吧！
Read more…