huge-pages

问题 I need help about managing Hugepages on raspberry pi 4 running raspberry pi OS 64 bit. I did not find much reliable information online. First I recompiled the kernel source enabling Memory Management options --->Transparent Hugepage Support option. When I run the command: grep -i huge /proc/meminfo The output is: AnonHugePages: 319488 kB ShmemHugePages: 0 kB FileHugePages: 0 k and running the command: cat /sys/kernel/mm/transparent_hugepage/enabled the output is: [always] madvise never So I

问题 I need help about managing Hugepages on raspberry pi 4 running raspberry pi OS 64 bit. I did not find much reliable information online. First I recompiled the kernel source enabling Memory Management options --->Transparent Hugepage Support option. When I run the command: grep -i huge /proc/meminfo The output is: AnonHugePages: 319488 kB ShmemHugePages: 0 kB FileHugePages: 0 k and running the command: cat /sys/kernel/mm/transparent_hugepage/enabled the output is: [always] madvise never So I

问题 I am looking to get the value of huge page size directly from my C code without to run a bash command. From bash i can do this grep pse /proc/cpuinfo > /dev/null && echo '2M huge page size are supported' grep pdpe1gb /proc/cpuinfo> /dev/null && echo '1G huge page size are supported' Secondly how to use mmap with 1G huge page size ? thanks Update snippet code #include <stdio.h> #include <limits.h> #include <hugetlbfs.h> int main(void){ long result1 = gethugepagesize(); printf( "%d\n", result1

问题 This question is for: kernel 3.10.0-1062.4.3.el7.x86_64 non transparent hugepages allocated via boot parameters and might or might not be mapped to a file (e.g. mounted hugepages) x86_64 According to this kernel source, move_pages() will call do_pages_move() to move a page, but I don't see how it indirectly calls migrate_huge_page(). So my questions are: can move_pages() move hugepages? if yes, should the page boundary be 4KB or 2MB when passing an array of addresses of pages? It seems like

问题 I downloaded libhugetlbfs.so and have a simple test source : int glbarr[1024*1024]={0} ; int main() { char * ptr ; ptr = (char *) malloc( 1024 * 1024 * 1 ) ; printf(" press any key to go on \n"); getchar() ; for(int idx=0;idx<100;idx++){ char strtmp[64] = {0} ; sprintf(strtmp,"%020d",idx) ; strcpy( ptr+1024*idx , strtmp ) ; } //for for(int idx=0;idx<100;idx++){ glbarr[idx] = idx ; } printf(" press any key to go on \n"); getchar() ; } // main then set the env : export LD_PRELOAD=libhugetlbfs

问题 I'm working in a driver that uses a buffer backed by hugepages, and I'm finding some problems with the sequentality of the hugepages. In userspace, the program allocates a big buffer backed by hugepages using the mmap syscall. The buffer is then communicated to the driver through a ioctl call. The driver uses the get_user_pages function to get the memory address of that buffer. This works perfectly with a buffer size of 1 GB (1 hugepage). get_user_pages returns a lot of pages ( HUGE_PAGE_SIZE

问题 My php-fpm process is facing performance issues on Ubuntu 14.04 LTS (Nginx server, MariaDB database). strace -f $(pidof php-fpm7.1 | sed 's/\([0-9]*\)/\-p \1/g') Gave me <... epoll_wait resumed> {}, 1, 1000) = 0 [pid 32533] epoll_wait(8, {}, 1, 103) = 0 [pid 32533] epoll_wait(8, <unfinished ...> [pid 32535] mmap(NULL, 2097152, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fd933fdd000 [pid 32535] munmap(0x7fd933fdd000, 2097152) = 0 [pid 32535] mmap(NULL, 4190208, PROT_READ|PROT

问题 Currently my application periodically blocked in IO , and the output is very low . I use some command to trace the process. By using jstack i found that the app is hanging at FileOutputStream.writeBytes. By using strace -f -c -p pid to collect syscall info, i found that. For normal situation, it has both futex and write syscalls. But when it went unnormal, there are only futex syscalls. The app keeps calling futex but all failed and throw ETIMEDOUT, just like this: <futex resumed> =-1

问题 On a fresh Ubuntu 16.04 EC2 instance the warnings appear like so: WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect. WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo

问题 I have a Java service that currently runs with a 14GB heap. I am keen to try out the -XX:+UseLargePages option to see how this might affect the performance of the system. I have configured the OS as described by Oracle using appropriate shared memory and page values (these can also be calculated with an online tool). Once the OS is configured, I can see that it allocates the expected amount of memory as huge-pages. However, starting the VM with the -XX:+UseLargePages option set always results