Re: iotop: khugepaged at 99.99% (2.6.38.3)

[Andrea Arcangeli <aarcange@redhat.com>]

On Thu, Sep 15, 2011 at 02:43:32PM +0800, Lin Ming wrote:
> # cat /proc/`pgrep khugepaged`/io
> 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?

Good idea to check it like that, yes that should confirm no
->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.

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.

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.