“swapper: page allocation failure”这个日志可忽略

我的messages里有很多这样的日志:

Nov 8 06:57:03 snnn kernel: [239273.336284] swapper: page allocation failure. order:4, mode:0x4020
Nov 8 06:57:03 snnn kernel: [239273.336292] Pid: 0, comm: swapper Not tainted 2.6.xx-xx-virtual #xx-Ubuntu

然后是kernel的Call Trace。很明显,这句话的意思是说内存不够了。据我对Call Trace的统计发现,无一例外都是在执行ip_finish_output函数的过程中使用kmalloc分配内存失败。

据我找到的资料看,这个是Xen特有的。

然后我从xen的邮件列表中找到一封06年的邮件,http://lists.xensource.com/archives/html/xen-devel/2006-12/msg00490.html,邮件里这么说:

“Harmless and not entirely unexpected. I'll add __GFP_NOWARN to the allocations to quieten things down. ”

同时在red hat的bugzilla上也找到了类似的问题,信中说,“The good news is this is just diagnostic, and not indication of an actual failure. The problem is we're trying to satisfy a fairly large allocation of a certain type, which after the machine has been up for a while, is difficult. We retry atomic allocations when they get failed, so the system keeps going.. ”。

于是可以放心的舒口气了。下面接着说到,

“That said, the driver shouldn't be asking for such obscene amounts of memory,
which is almost guaranteed to fail. There is ongoing work upstream to make the
family of e100* drivers not do this.”

我没做过linux kernel开发,所以我很为不解。按我的日志来看,order通常都是3、4或5。也就是说请求8到32个物理页面的时候失败。我的物理内存总数是242M,free大致保持在12M左右,但是因为长期运行而导致内存碎片增多的原因,找不到连续的32K的物理内存给网卡驱动用?

这个模型是这样:从1到n中选取m个互不相同的自然数排成一排(m\<n),任何相邻的两个自然数之差不大于k的概率是多少?可惜我概率学的很浅,没有学到这个。

今天在王旭的blog上看他说Xen已经是黄土没膝了。另外这篇文章也让我看得觉得比较悲剧,中文译文在这里。我现在这家公司,其它同事的工作也主要是集中在kvm上而不是xen。传说虚拟化技术是计算机技术中集大成者,颇像数论在数学中的地位那样,所以我不敢妄谈它俩的比较。

此博客中的热门博文

在windows下使用llvm+clang

少写代码,多读别人写的代码

tensorflow distributed runtime初窥