On Thu, Sep 15, 2011 at 02:43:32PM +0800, Lin Ming wrote:I tried with previous kernel (2.6.40.3-0.fc15) and I haven't seen this problem when running the PC for 24 hours and building code in a loop inside the VM. With 2.6.40.4-5.fc15 I get it after a few hours.# cat /proc/`pgrep khugepaged`/ioGood idea to check it like that, yes that should confirm no
rchar: 0
wchar: 0
syscr: 0
syscw: 0
read_bytes: 0
write_bytes: 0
cancelled_write_bytes: 0
Andrea,
From above output, all fields are zero.
Does it mean that transparent huge page was not triggered/used at all?
->writepage was called by khugepaged through
compaction->migrate->writepage.
It may have been used for migration, but the compaction code run by
khugepaged didn't trigger writes, or the write_bytes should have been
0.With regard to Slawomir's problem, the kernel
kernel-PAE-2.6.40.4-5.fc15.i686 includes Mel's fix for the compaction
scan to stay in the right zone.
For a long time there were just zeros appearing. After stalls started I got this:
Slawomir could you run the command "cat /proc/`pgrep khugepaged`/io"
as root, so see if there's significant writeout going from khugepaged?
If there is you can try the patch in the below link.I don't have EPT/NTP in /proc/cpuinfo. CPU is AMD Phenom(tm) II X6 1100T Processor
https://lkml.org/lkml/2011/7/26/103
But the fact it happens on top of VMplayer with a PAE guest, may also
be a variable to take into account, migrate does quite some pagetable
work. If VMplayer uses EPT/NTP (do you have EPT/NTP available as VT
feature in the host /proc/cpuinfo?) it's hard to see how that could be
related.