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
next parent 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.