All of lore.kernel.org
 help / color / mirror / Atom feed
From: Slawomir Czarko-Wasiutycz <slawomir.czarko@gmail.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Lin Ming <mlin@ss.pku.edu.cn>,
	fa.linux.kernel@googlegroups.com,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Sattler <tsattler@gmx.de>,
	Johannes Weiner <jweiner@redhat.com>,
	Mel Gorman <mgorman@suse.de>
Subject: Re: iotop: khugepaged at 99.99% (2.6.38.3)
Date: Tue, 20 Sep 2011 15:19:45 +0200	[thread overview]
Message-ID: <4E7892F1.1000107@gmail.com> (raw)
In-Reply-To: <20110919175159.GL7800@redhat.com>

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.


  reply	other threads:[~2011-09-20 14:56 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.FZDTDqnxL4JfQvyaCQTn405rzwM@ifi.uio.no>
2011-09-14 12:57 ` iotop: khugepaged at 99.99% (2.6.38.3) Slawomir Czarko-Wasiutycz
2011-09-14 13:32   ` Slawomir Czarko-Wasiutycz
2011-09-15  6:43   ` Lin Ming
2011-09-15  6:48     ` Lin Ming
2011-09-15  7:24       ` Thomas Sattler
2011-09-15  7:50         ` Lin Ming
2011-09-19 17:51     ` Andrea Arcangeli
2011-09-20 13:19       ` Slawomir Czarko-Wasiutycz [this message]
2011-04-20 23:28 Thomas Sattler
2011-04-27 13:46 ` Andrea Arcangeli
2011-05-04 12:20   ` Thomas Sattler
2011-05-04 12:37     ` Thomas Sattler
2011-05-04 14:38     ` Andrea Arcangeli
2011-05-05 13:08       ` Thomas Sattler
2011-05-11 10:53 ` Ulrich Keller
2011-05-12 14:03   ` Andrea Arcangeli
2011-05-16  9:27     ` Ulrich Keller
2011-05-16 12:29       ` Ulrich Keller
2011-05-23 18:05     ` Johannes Hirte
2011-05-25 16:06       ` Andrea Arcangeli
2011-05-25 20:44         ` Thomas Sattler
2011-06-01 19:37     ` Gilles Hamel
2011-06-13 10:28 ` Antonio Messina

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E7892F1.1000107@gmail.com \
    --to=slawomir.czarko@gmail.com \
    --cc=aarcange@redhat.com \
    --cc=fa.linux.kernel@googlegroups.com \
    --cc=jweiner@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mlin@ss.pku.edu.cn \
    --cc=tsattler@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.