All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zhouping Liu <zliu@redhat.com>
To: Andrea Arcangeli <aarcange@redhat.com>,
	David Rientjes <rientjes@google.com>,
	Mel Gorman <mgorman@suse.de>, Hugh Dickins <hughd@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>, linux-mm@kvack.org
Subject: [BUG?] thp: too much anonymous hugepage caused 'khugepaged' thread stopped
Date: Sun, 7 Apr 2013 02:29:30 -0400 (EDT)	[thread overview]
Message-ID: <338291050.277410.1365316170850.JavaMail.root@redhat.com> (raw)
In-Reply-To: <1101781431.260745.1365313808038.JavaMail.root@redhat.com>

Hello All,

When I did some testing to check thp's performance, the following
strange action occurred:

when a process try to allocate 500+(or other large value)
anonymous hugepage, the 'khugepaged' thread will stop to
scan vma. the testing system has 2Gb RAM, and the thp
enabled value is 'always', set 0 to 'scan_sleep_millisecs'

you can use the following steps to confirm the issue:

---------------- example code ------------
/* file test_thp.c */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>

int main(int argc, char *argv[])
{
	int nr_thps = 1000, ret = 0;
	unsigned long hugepagesize, size;
	void *addr;

	hugepagesize = (1UL << 21);

	if (argc == 2)
		nr_thps = atoi(argv[1]);

	printf("try to allocate %d transparent hugepages\n", nr_thps);
	size = (unsigned long)nr_thps * hugepagesize;

	ret = posix_memalign(&addr, hugepagesize, size);
	if (ret != 0) {
		printf("posix_memalign failed\n");
		return ret;
	}

	memset (addr, 10, size);

	sleep(50);

	return ret;
}
-------- end example code -----------

executing './test_thp 500' in a system with 2GB RAM, the values in
/sys/kernel/mm/transparent_hugepage/khugepaged/* will never change,
you can  repeatedly do '# cat /sys/kernel/mm/transparent_hugepage/khugepaged/*' to check this.

as we know, when we set 0 to /sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs,
the /sys/kernel/mm/transparent_hugepage/khugepaged/full_to_scans will increasing at least,
but the actual is opposite, the value is never change, so I checked 'khugepaged' thread,
and found the 'khugepaged' is stopped:
# ps aux | grep -i hugepaged
root        67 10.9  0.0      0     0 ?        SN   Apr06 172:10 [khugepaged]
                                               ^^ 
also I did the same actions on some large machine, e.g on 16Gb RAM, 1000+ anonymous hugepages
will cause 'khugepaged' stopped, but there are 2Gb+ free memory, why is it? is that normal?
comments?

-- 
Thanks,
Zhouping

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Zhouping Liu <zliu@redhat.com>
To: Andrea Arcangeli <aarcange@redhat.com>,
	David Rientjes <rientjes@google.com>,
	Mel Gorman <mgorman@suse.de>, Hugh Dickins <hughd@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>, linux-mm@kvack.org
Subject: [BUG?] thp: too much anonymous hugepage caused 'khugepaged' thread stopped
Date: Sun, 7 Apr 2013 02:29:30 -0400 (EDT)	[thread overview]
Message-ID: <338291050.277410.1365316170850.JavaMail.root@redhat.com> (raw)
In-Reply-To: <1101781431.260745.1365313808038.JavaMail.root@redhat.com>

Hello All,

When I did some testing to check thp's performance, the following
strange action occurred:

when a process try to allocate 500+(or other large value)
anonymous hugepage, the 'khugepaged' thread will stop to
scan vma. the testing system has 2Gb RAM, and the thp
enabled value is 'always', set 0 to 'scan_sleep_millisecs'

you can use the following steps to confirm the issue:

---------------- example code ------------
/* file test_thp.c */

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/mman.h>

int main(int argc, char *argv[])
{
	int nr_thps = 1000, ret = 0;
	unsigned long hugepagesize, size;
	void *addr;

	hugepagesize = (1UL << 21);

	if (argc == 2)
		nr_thps = atoi(argv[1]);

	printf("try to allocate %d transparent hugepages\n", nr_thps);
	size = (unsigned long)nr_thps * hugepagesize;

	ret = posix_memalign(&addr, hugepagesize, size);
	if (ret != 0) {
		printf("posix_memalign failed\n");
		return ret;
	}

	memset (addr, 10, size);

	sleep(50);

	return ret;
}
-------- end example code -----------

executing './test_thp 500' in a system with 2GB RAM, the values in
/sys/kernel/mm/transparent_hugepage/khugepaged/* will never change,
you can  repeatedly do '# cat /sys/kernel/mm/transparent_hugepage/khugepaged/*' to check this.

as we know, when we set 0 to /sys/kernel/mm/transparent_hugepage/khugepaged/scan_sleep_millisecs,
the /sys/kernel/mm/transparent_hugepage/khugepaged/full_to_scans will increasing at least,
but the actual is opposite, the value is never change, so I checked 'khugepaged' thread,
and found the 'khugepaged' is stopped:
# ps aux | grep -i hugepaged
root        67 10.9  0.0      0     0 ?        SN   Apr06 172:10 [khugepaged]
                                               ^^ 
also I did the same actions on some large machine, e.g on 16Gb RAM, 1000+ anonymous hugepages
will cause 'khugepaged' stopped, but there are 2Gb+ free memory, why is it? is that normal?
comments?

-- 
Thanks,
Zhouping

       reply	other threads:[~2013-04-07  6:29 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1101781431.260745.1365313808038.JavaMail.root@redhat.com>
2013-04-07  6:29 ` Zhouping Liu [this message]
2013-04-07  6:29   ` [BUG?] thp: too much anonymous hugepage caused 'khugepaged' thread stopped Zhouping Liu
2013-04-07  7:10   ` Wanpeng Li
2013-04-07  7:45     ` Zhouping Liu
2013-04-07  7:45       ` Zhouping Liu
2013-04-07  8:33     ` Wanpeng Li
2013-04-07  8:33     ` Wanpeng Li
2013-04-07  7:10   ` Wanpeng Li

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=338291050.277410.1365316170850.JavaMail.root@redhat.com \
    --to=zliu@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=rientjes@google.com \
    /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.