7-Zip 26.01 - Linux huge pages provide a solid 2.5–4.5% compression speedup on modern and cache-limited CPUs by reducing TLB overhead, but offer zero benefit for decompression or ancient hardware. #memorymanagement #x86 #hugepages #largepages #7zip #linux #compression #datacompression #benchmark #performance
Попробовал попердолиться с Huge pages. Взять lmbench, в bw_mem заменил malloc на mmap с MAP_HUGETLB, запустил тест bcopy.
Получилось медленнее, чем с обычным malloc! (А malloc-то внутри такой же mmap, только без MAP_HUGETLB), аж на целых 25%.
Я могу понять, почему это не быстрее, ладно. Но почему оно может быть медленнее, не понимаю.
Особенности архитектуры? Я смотрю на PPC64. #Linux #hugepages
Vous avez peut être loupé, mais cette semaine j'ai posté la traduction (de EN vers FR) d'un super article d'Alexandr Nikitin sur comment mesurer l'impact (parfois positif !) des mal aimées #Transparent #Hugepages. J'espère que ça pourra être utile !
https://blog.zwindler.fr/2020/02/24/transparent-hugepages-mesurer-limpact-sur-les-performances/
Transparent Hugepages : mesurer l’impact sur les performances

Encore les Transparent Hugepages ? Il y a quelques jours, j’ai posté un article pour vous aider à désactiver les Transparent Hugepages. A là suite de ça, Seboss666 (qui tient un super blog bien Geek/sysadmin comme j’aime) m’a fait remarquer en commentaire que j’expliquais surtout comment désactiver les THP. Mais je n’ai pas beaucoup parlé d’à quoi ça sert (à part que c’est mal aimé, comme SELinux) et si ça a vraiment un impact sur les perfs.

Zwindler's Reflection

finally managed to configure 4x 1GB #HugePages on my #Debian.

`/etc/default/grub`:
```
GRUB_CMDLINE_LINUX_DEFAULT="hugepagesz=1GB default_hugepagesz=1GB hu
gepages=4"
```

`/etc/group`:
```
hugetlb:x:1003:claude
```

`/etc/fstab`:
```
hugetlbfs /dev/hugepages hugetlbfs mode=1770,gid=1003,pagesize=1GB 0 0
```

`/etc/sysctl.conf`:
```
vm.nr_hugepages = 4
vm.hugetlb_shm_group = 1003
```

reboot

`my-code.c++`:
```
#define MAP_HUGE_1GB (30 << MAP_HUGE_SHIFT)
data = (unsigned char *) mmap(nullptr, bytes, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_HUGETLB | MAP_HUGE_1GB | MAP_ANONYMOUS, -1, 0);
if (data != MMAP_FAILED)
size_t read_bytes = 0;
do
{
ssize_t result = read(fd, data + read_bytes, bytes - read_bytes);
if (result <= 0)
{
break;
}
read_bytes += result;
} while (read_bytes < bytes);
if (read_bytes == bytes)
/* :-) */;
}
```
in particular, MAP_ANONYMOUS seems to be required for MAP_HUGETLB, which means specifying -1 instead of the fd directly, and reading the data later (which needs PROT_WRITE). the loop is because read won't more than 0x7ffff000 bytes at once.

don't know if all of this is necessary, but it works now (I may have missed some steps, tried a few different things before success).

ref: https://wiki.debian.org/Hugepages
ref: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/tools/testing/selftests/vm/map_hugetlb.c?h=v5.2.14

Hugepages - Debian Wiki

New Blog article…

Here’s my take on how "Mesh: Compacting Memory Management for C/C Applications" relates to GSlice:

GSlice considerations and possible improvements

https://testbit.eu/2019/gslice-considerations

#GSlice #MESH #Slab #Hugepages #HUGETLB #Malloc #memalign etc

GSlice considerations and possible improvements | Timj’s bits and tests