LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: Barry Song <21cnbao@gmail.com> To: Muchun Song <songmuchun@bytedance.com> Cc: mike.kravetz@oracle.com, Andrew Morton <akpm@linux-foundation.org>, osalvador@suse.de, mhocko@suse.com, Barry Song <song.bao.hua@hisilicon.com>, david@redhat.com, chenhuang5@huawei.com, bodeddub@amazon.com, Jonathan Corbet <corbet@lwn.net>, Matthew Wilcox <willy@infradead.org>, duanxiongchun@bytedance.com, fam.zheng@bytedance.com, smuchun@gmail.com, zhengqi.arch@bytedance.com, linux-doc@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>, Linux-MM <linux-mm@kvack.org> Subject: Re: [PATCH RESEND v2 4/4] selftests: vm: add a hugetlb test case Date: Sat, 18 Sep 2021 17:20:09 +1200 [thread overview] Message-ID: <CAGsJ_4wW6b5aC4va1_BZuWLqxzRkSi3vLcyJo7XGMbVi8i7iuw@mail.gmail.com> (raw) In-Reply-To: <20210917034815.80264-5-songmuchun@bytedance.com> On Sat, Sep 18, 2021 at 12:08 AM Muchun Song <songmuchun@bytedance.com> wrote: > > Since the head vmemmap page frame associated with each HugeTLB page is > reused, we should hide the PG_head flag of tail struct page from the > user. Add a tese case to check whether it is work properly. > TBH, I am a bit confused. I was thinking about some kernel unit tests to make sure those kernel APIs touched by this patchset are still working as before. This userspace test, while certainly useful for checking the content of page frames as expected, doesn't directly prove things haven't changed. In patch 1/4, a couple of APIs have the fixup for the fake head issue. Do you think a test like the below would be more sensible? 1. alloc 2MB hugeTLB 2. get each page frame 3. apply those APIs in each page frame 4. Those APIs work completely the same as before. > Signed-off-by: Muchun Song <songmuchun@bytedance.com> > --- > tools/testing/selftests/vm/vmemmap_hugetlb.c | 139 +++++++++++++++++++++++++++ > 1 file changed, 139 insertions(+) > create mode 100644 tools/testing/selftests/vm/vmemmap_hugetlb.c > > diff --git a/tools/testing/selftests/vm/vmemmap_hugetlb.c b/tools/testing/selftests/vm/vmemmap_hugetlb.c > new file mode 100644 > index 000000000000..b6e945bf4053 > --- /dev/null > +++ b/tools/testing/selftests/vm/vmemmap_hugetlb.c > @@ -0,0 +1,139 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * A test case of using hugepage memory in a user application using the > + * mmap system call with MAP_HUGETLB flag. Before running this program > + * make sure the administrator has allocated enough default sized huge > + * pages to cover the 2 MB allocation. > + * > + * For ia64 architecture, Linux kernel reserves Region number 4 for hugepages. > + * That means the addresses starting with 0x800000... will need to be > + * specified. Specifying a fixed address is not required on ppc64, i386 > + * or x86_64. > + */ > +#include <stdlib.h> > +#include <stdio.h> > +#include <unistd.h> > +#include <sys/mman.h> > +#include <fcntl.h> > + > +#define MAP_LENGTH (2UL * 1024 * 1024) > + > +#ifndef MAP_HUGETLB > +#define MAP_HUGETLB 0x40000 /* arch specific */ > +#endif > + > +#define PAGE_SIZE 4096 > + > +#define PAGE_COMPOUND_HEAD (1UL << 15) > +#define PAGE_COMPOUND_TAIL (1UL << 16) > +#define PAGE_HUGE (1UL << 17) > + > +#define HEAD_PAGE_FLAGS (PAGE_COMPOUND_HEAD | PAGE_HUGE) > +#define TAIL_PAGE_FLAGS (PAGE_COMPOUND_TAIL | PAGE_HUGE) > + > +#define PM_PFRAME_BITS 55 > +#define PM_PFRAME_MASK ~((1UL << PM_PFRAME_BITS) - 1) > + > +/* Only ia64 requires this */ > +#ifdef __ia64__ > +#define MAP_ADDR (void *)(0x8000000000000000UL) > +#define MAP_FLAGS (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB | MAP_FIXED) > +#else > +#define MAP_ADDR NULL > +#define MAP_FLAGS (MAP_PRIVATE | MAP_ANONYMOUS | MAP_HUGETLB) > +#endif > + > +static void write_bytes(char *addr, size_t length) > +{ > + unsigned long i; > + > + for (i = 0; i < length; i++) > + *(addr + i) = (char)i; > +} > + > +static unsigned long virt_to_pfn(void *addr) > +{ > + int fd; > + unsigned long pagemap; > + > + fd = open("/proc/self/pagemap", O_RDONLY); > + if (fd < 0) > + return -1UL; > + > + lseek(fd, (unsigned long)addr / PAGE_SIZE * sizeof(pagemap), SEEK_SET); > + read(fd, &pagemap, sizeof(pagemap)); > + close(fd); > + > + return pagemap & ~PM_PFRAME_MASK; > +} > + > +static int check_page_flags(unsigned long pfn) > +{ > + int fd, i; > + unsigned long pageflags; > + > + fd = open("/proc/kpageflags", O_RDONLY); > + if (fd < 0) > + return -1; > + > + lseek(fd, pfn * sizeof(pageflags), SEEK_SET); > + > + read(fd, &pageflags, sizeof(pageflags)); > + if ((pageflags & HEAD_PAGE_FLAGS) != HEAD_PAGE_FLAGS) { > + close(fd); > + printf("Head page flags (%lx) is invalid\n", pageflags); > + return -1; > + } > + > + for (i = 1; i < MAP_LENGTH / PAGE_SIZE; i++) { > + read(fd, &pageflags, sizeof(pageflags)); > + if ((pageflags & TAIL_PAGE_FLAGS) != TAIL_PAGE_FLAGS || > + (pageflags & HEAD_PAGE_FLAGS) == HEAD_PAGE_FLAGS) { > + close(fd); > + printf("Tail page flags (%lx) is invalid\n", pageflags); > + return -1; > + } > + } > + > + close(fd); > + > + return 0; > +} > + > +int main(int argc, char **argv) > +{ > + void *addr; > + unsigned long pfn; > + > + addr = mmap(MAP_ADDR, MAP_LENGTH, PROT_READ | PROT_WRITE, MAP_FLAGS, -1, 0); > + if (addr == MAP_FAILED) { > + perror("mmap"); > + exit(1); > + } > + > + /* Trigger allocation of HugeTLB page. */ > + write_bytes(addr, MAP_LENGTH); > + > + pfn = virt_to_pfn(addr); > + if (pfn == -1UL) { > + munmap(addr, MAP_LENGTH); > + perror("virt_to_pfn"); > + exit(1); > + } > + > + printf("Returned address is %p whose pfn is %lx\n", addr, pfn); > + > + if (check_page_flags(pfn) < 0) { > + munmap(addr, MAP_LENGTH); > + perror("check_page_flags"); > + exit(1); > + } > + > + /* munmap() length of MAP_HUGETLB memory must be hugepage aligned */ > + if (munmap(addr, MAP_LENGTH)) { > + perror("munmap"); > + exit(1); > + } > + > + return 0; > +} > -- > 2.11.0 > Thanks Barry
next prev parent reply other threads:[~2021-09-18 5:20 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-09-17 3:48 [PATCH RESEND v2 0/4] Free the 2nd vmemmap page associated with each HugeTLB page Muchun Song 2021-09-17 3:48 ` [PATCH RESEND v2 1/4] mm: hugetlb: free " Muchun Song 2021-09-18 4:38 ` Barry Song 2021-09-18 10:06 ` Muchun Song 2021-09-21 6:43 ` Muchun Song 2021-09-21 10:22 ` Muchun Song 2021-09-21 0:11 ` Barry Song 2021-09-21 13:46 ` Muchun Song 2021-09-21 20:43 ` Barry Song 2021-09-22 2:38 ` Muchun Song 2021-09-22 7:36 ` Barry Song 2021-09-17 3:48 ` [PATCH RESEND v2 2/4] mm: hugetlb: replace hugetlb_free_vmemmap_enabled with a static_key Muchun Song 2021-09-18 4:55 ` Barry Song 2021-09-18 10:30 ` Muchun Song 2021-09-18 11:14 ` Barry Song 2021-09-18 11:47 ` Muchun Song 2021-09-18 12:27 ` Barry Song 2021-09-17 3:48 ` [PATCH RESEND v2 3/4] mm: sparsemem: use page table lock to protect kernel pmd operations Muchun Song 2021-09-18 5:06 ` Barry Song 2021-09-18 10:51 ` Muchun Song 2021-09-18 11:01 ` Barry Song 2021-09-17 3:48 ` [PATCH RESEND v2 4/4] selftests: vm: add a hugetlb test case Muchun Song 2021-09-18 5:20 ` Barry Song [this message] 2021-09-20 14:26 ` Muchun Song 2021-09-21 0:28 ` Barry Song 2021-09-21 13:18 ` Muchun Song
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=CAGsJ_4wW6b5aC4va1_BZuWLqxzRkSi3vLcyJo7XGMbVi8i7iuw@mail.gmail.com \ --to=21cnbao@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=bodeddub@amazon.com \ --cc=chenhuang5@huawei.com \ --cc=corbet@lwn.net \ --cc=david@redhat.com \ --cc=duanxiongchun@bytedance.com \ --cc=fam.zheng@bytedance.com \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mhocko@suse.com \ --cc=mike.kravetz@oracle.com \ --cc=osalvador@suse.de \ --cc=smuchun@gmail.com \ --cc=song.bao.hua@hisilicon.com \ --cc=songmuchun@bytedance.com \ --cc=willy@infradead.org \ --cc=zhengqi.arch@bytedance.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).