linux-kernel - Re: iotop: khugepaged at 99.99% (2.6.38.3)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 20 Sep 2011 15:19:45 +0200
From:	Slawomir Czarko-Wasiutycz <slawomir.czarko@...il.com>
To:	Andrea Arcangeli <aarcange@...hat.com>
CC:	Lin Ming <mlin@...pku.edu.cn>, fa.linux.kernel@...glegroups.com,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Thomas Sattler <tsattler@....de>,
	Johannes Weiner <jweiner@...hat.com>,
	Mel Gorman <mgorman@...e.de>
Subject: Re: iotop: khugepaged at 99.99% (2.6.38.3)

On 09/19/2011 07:51 PM, Andrea Arcangeli wrote:
> 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.
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.

>
> Slawomir could you run the command "cat /proc/`pgrep khugepaged`/io"
> as root, so see if there's significant writeout going from khugepaged?
For a long time there were just zeros appearing. After stalls started I 
got this:
[root]# cat /proc/`pgrep khugepaged`/io
rchar: 0
wchar: 0
syscr: 0
syscw: 0
read_bytes: 0
write_bytes: 24576
cancelled_write_bytes: 0

and after some time:

[root]# cat /proc/`pgrep khugepaged`/io
rchar: 0
wchar: 0
syscr: 0
syscw: 0
read_bytes: 0
write_bytes: 32768
cancelled_write_bytes: 0

> 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.
I don't have EPT/NTP in /proc/cpuinfo. CPU is AMD Phenom(tm) II X6 1100T 
Processor

Here are the flags from /proc/cpuinfo:

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext 
fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc nonstop_tsc 
extd_apicid aperfmperf pni monitor cx16 popcnt lahf_lm cmp_legacy svm 
extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit 
wdt cpb npt lbrv svm_lock nrip_save pausefilter

I'll build a kernel with the suggested patch and give it a try.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/