发表于
2014-07-15 07:40:03
自修DELL笔记本
发表于
2014-05-10 08:30:27
发表于
2014-04-24 09:54:24
追踪CPU跑满
最近测试一个应用遇到问题：一旦压力略涨，应用的CPU就顶满。由于是多线程应用，直接就把系统的CPU耗完了。本来想用gdb來调试的，结果gdb不给力，就在attach那里卡死，半天不动。后来想到了用perf来调试，果然找到了一处性能热点。修复热点以后，CPU顶满的问题缓解了一些，不太容易出现了，但是，多跑一会儿，还是会有。而且现在出现CPU顶满时，不仅gdb不返回，连perf record -a -g都无法用Ctrl+c来停止了，仔细top命令看了一下，原来系统的sys是100%，usr几乎为0%，也就是说，是卡在内核里了，难怪perf不好使。perf这样的神器都用不了了，还能怎么办？最后@coly提醒我：用 echo t > /proc/sysrq-trigger 把内核栈整个打出来。好办法，我试了一下，dmesg里一堆信息：Apr 25 22:37:57 v3 kernel: sheep R running task 0 19157 1 0x10000080
Apr 25 22:37:57 v3 kernel: ffff8802b41c5418 0000000000000086 ffff88028761ecc0 ffffea0008b0f478
Apr 25 22:37:57 v3 kernel: ffffffff814ef33e fff
...继续阅读
(111)
发表于
2014-04-16 06:18:00
发表于
2014-04-02 08:09:31
LSF/MM Summit 2014
作者：刘峥今年LSF/MM会议的内容lwn.net上已经有文章进行详细的介绍了。鉴于我本人分身乏术造成mm track基本没有听，同时会上讨论的有些问题本人理解也十分有限，所以推荐大家还是去lwn.net上看一下上面的文章。这里仅仅是总结我认为比较重要和关注的问题，希望通过这篇文章能让大家了解目前Linux Kernel在文件系统、存储和内存管理方面需要解决的问题。这次的LSF/MM会议的议题基本可以分为三个大的部分：Linux Kernel目前存在的问题来自业界和社区的分享新技术带来的新问题尽管1中的议题占了会议的大部分时间，但是个人感觉这次LSF/MM最重要的是2、3两部分。而且会对未来一段时间的内核开发带来较大的影响。1. Linux Kernel目前存在的问题这一部分包含了如下内容：Page Cache的相关问题测试blk-mq的相关问题direct I/O1) Page Cache的相关问题这次LSF/MM上关于page cache的讨论有两个，一个是关于32位机器上大空间块设备寻址的历史遗留问题；另一个是支持大于4k内存页的page cache。32位机器上对于大空间块设备寻址是一个历史遗留问题。这个问题说来很简单，32位机器的内存寻址范围是2^32=4GB，目前Linux Kernel常规内存页大小为4k，因此对于系统page cache来讲，最大可以支持的磁盘设备的
...继续阅读
(96)
发表于
2014-03-31 02:09:38
Ext4 Workshop 2014
作者：刘峥2014年3月26日，Napa Valley, CA. 今年LSF/MM Summit 2014会议就在这里举行，因此Ext4 Workshop相应的也就在这里了。会议内容主要是讨论后续一年Ext4文件系统的开发问题。今年讨论的内容如下：Data Block ChecksumsReflinkEncryptionExtent Cache ShrinkerBuffer_head RemovalSMR/Flash Device OptimizationMulti-block AllocationTestingMount Options Restrict与会人员：Ted Ts'o (Google, Ext4/Jbd2 Maintainer)Jan Kara (SUSE, Ext3/Jbd Maintainer)Ric Wheeler (Redhat)Eric Sandeen (Redhat)Lukas Cerner (Redhat)Carlos Maiolino (Redhat)Darrick Wong (Oracle)Zheng Liu (Alibaba)Michael Halcrow (Google)Eric Whitney两位来自Western Digital的工程师1. Data Block Checksums目前Ext4已经具备对元数据进行校验的能力。如果需要对文件系
...继续阅读
(99)
发表于
2014-03-24 03:20:05
debuginfo的rpm包
之前rpmbuild -ba xxx.spec能自动打出binary包和对应的debuginfo包，但是我不想分成两个包，希望binary包里就是带调试符号的，在网上找了一堆，最简单的办法就是在spec文件里（头部）加一句%global debug_package %{nil}那些说在~/.rpmmacros里加东西的办法似乎都不好使。但是，几天后，我在另一台机器上又遇到了相反的问题：rpmbuild -ba xxx.spec默认就不打debuginfo包。估计是机器的环境问题，不过谁知道又是哪个文件闹的环境问题呢？于是又检查了一圈，哦，原来是没有装redhat-rpm-config包，所以没有bsp-compress这个工具，故而打不出debuginfo包来。机器上的软件环境，是个头疼的事，看来，docker也许真有搞头。
...继续阅读
(108)
发表于
2014-02-13 09:07:23
神器valgrind
其实早在2006年我就用过valgrind，但当时valgrind不能观测daemon的内存泄漏问题，所以后来渐渐用得少了。今天又遇到一个内存泄漏问题，程序颇大，手工调试不太现实了，所以又想到了valgrind，毕竟在这7年间，valgrind又强大了不少。查了一下，它已经可以检测daemon进程了，方法在这里对应的官方文档在这里其中"monitor leak_check full reachable any"相当于设置gdb的breakpoint。不过，我要调试的这个程序，一运行就fork了，然后子进程负责主要的逻辑，父进程只是等待子进程返回用的，而且，只在运行某个特殊逻辑时出现内存泄漏，平时的逻辑没有问题。怎么弄？折腾了一下，发现可以搞定：首先，在gdb里运行“set follow-fork-mode child”来自动跟踪子进程，然后，一开始不要急着用”monitor leak_check full reachable any"来检测，先"continue“运行一阵子，当开始跑造成内存泄漏的逻辑时，再ctrl+c打断，再”monitor leak_check full reachable any“设上断点，自然会吐出valgrind的memleak信息。用这两招，果然找到内存泄漏的点了，隐藏颇深，如果不是用工具，真不知何年何月才能发现。感谢valgrind神器，支持vgdb支
...继续阅读
(220)
发表于
2014-02-13 04:40:21
小问题汇总
最近遇到一些开发部署等方面的几个小问题，留个笔记。第一个 编程问题#include
#include
#include
int main(int argc, char *argv[])
{
int ret;
pthread_mutex_t mt;
ret = pthread_mutex_init(&mt, NULL);
if (ret != 0) {
printf("failed to init (ret: %d)\n", ret);
goto fail;
}
ret = pthread_mutex_unlock(&mt);
if (ret != 0) {
printf("failed to unlock (ret: %d)\n", ret);
goto fail;
}
ret = pthread_mutex_destroy(&mt);
if (ret != 0) {
printf("failed to destroy (ret: %d)\n", ret);
goto fail;
}
printf("complete\n");
return 0;
fail:
printf("fail\n");
return -1;
}#编译
gcc test.c -o test -lpthread
#运
...继续阅读
(88)