4 ms·

AFAIK, FreeBSD has been doing transparent superpages for decades (I think it was implemented in 2002 for x86 [1], and 2014 for arm [2]) and I don't know of any

by toast0 3mo ago

AFAIK, FreeBSD has been doing transparent superpages for decades (I think it was implemented in 2002 for x86 [1], and 2014 for arm [2]) and I don't know of any real issues with it? (I'm sure you could build a test case where it thrashes and causes trouble) Not sure why Linux wouldn't do the same?? [1] https://www.usenix.org/legacy/events/osdi02/tech/full_papers/navarro/navarro.pdf https://www.usenix.org/legacy/events/osdi02/tech/full_papers... [2] https://www.bsdcan.org/2014/schedule/attachments/281_2014_arm_superpages-paper.pdf https://www.bsdcan.org/2014/schedule/attachments/281_2014_ar...

jeffbee 3mo ago
Linux also has support for it but it is up to the distribution, or the user, to enable or disable it. The whole discourse was poisoned years ago when the author of Redis told everyone to disable THP on Linux, but this was caused by Redis being a poor program, not by THP being a poor feature. Unfortunately, even though the Redis project finally removed their document about this, many people still carry this bias.
- matheusmoreira 3mo ago
  > The whole discourse was poisoned years ago when the author of Redis told everyone to disable THP on Linux What's the story behind that? Do normal programs really get affected by this? Normal programs are most likely using glibc's memory allocator, and I'd be surprised if it was incapable of handling arbitrary page sizes. Only reason why I have to care is I implemented my own memory allocator.
  - jeffbee 3mo ago
    Redis uses jemalloc by default, if I recall correctly, but its hostility to the way systems actually work arises from the way that it forks, then changes one bit on every page in the entire virtual space, which causes a lot of kernel work to support copy-on-write by blowing up huge pages into smaller pages. That's what happens when your program is antagonistic to the way the machine actually works.
    - matheusmoreira 3mo ago
      > then changes one bit on every page in the entire virtual space Yeah that sucks. Naively implemented garbage collectors have the same problem: they put the live and mark bits in the object itself which spreads those bits all over the address space. This leads to the garbage collector touching every single page when it scans and writes all of those bits. The proper solution is to allocate separate bitmap pages. This dramatically improves cache efficiency. Machines always want a structure of arrays.
      - evntdrvn 3mo ago
        I've always struggled a bit with the fact that "machines want SoA but readability/clarity/etc is easier with AoS". And wonder if it would be possible for a language to have the code representation be AoS but the implementation transparently be SoA.
        yvdriess 3mo ago
        Pretty old, but a good example of how such an abstraction works: https://github.com/ExaScience/arrow-street https://github.com/ExaScience/arrow-street
    - toast0 3mo ago
      Thanks for explaining, I can see how it got to where it is.
- deleted 3mo ago
  [deleted]
- mnw21cam 3mo ago
  There was also an issue with Linux about 8 years ago where the THP daemon would start busy-looping searching for pages to amalgamate, wasting loads of CPU time (and I believe freezing the processes it was inspecting), and so people were advising switching off THP for that reason until it was fixed. It hit our large Java processes quite badly.

by toast0 3mo ago

jeffbee 3mo ago

Linux also has support for it but it is up to the distribution, or the user, to enable or disable it. The whole discourse was poisoned years ago when the author of Redis told everyone to disable THP on Linux, but this was caused by Redis being a poor program, not by THP being a poor feature. Unfortunately, even though the Redis project finally removed their document about this, many people still carry this bias.

matheusmoreira 3mo ago
> The whole discourse was poisoned years ago when the author of Redis told everyone to disable THP on Linux What's the story behind that? Do normal programs really get affected by this? Normal programs are most likely using glibc's memory allocator, and I'd be surprised if it was incapable of handling arbitrary page sizes. Only reason why I have to care is I implemented my own memory allocator.
- jeffbee 3mo ago
  Redis uses jemalloc by default, if I recall correctly, but its hostility to the way systems actually work arises from the way that it forks, then changes one bit on every page in the entire virtual space, which causes a lot of kernel work to support copy-on-write by blowing up huge pages into smaller pages. That's what happens when your program is antagonistic to the way the machine actually works.
  - matheusmoreira 3mo ago
    > then changes one bit on every page in the entire virtual space Yeah that sucks. Naively implemented garbage collectors have the same problem: they put the live and mark bits in the object itself which spreads those bits all over the address space. This leads to the garbage collector touching every single page when it scans and writes all of those bits. The proper solution is to allocate separate bitmap pages. This dramatically improves cache efficiency. Machines always want a structure of arrays.
    - evntdrvn 3mo ago
      I've always struggled a bit with the fact that "machines want SoA but readability/clarity/etc is easier with AoS". And wonder if it would be possible for a language to have the code representation be AoS but the implementation transparently be SoA.
      - yvdriess 3mo ago
        Pretty old, but a good example of how such an abstraction works: https://github.com/ExaScience/arrow-street https://github.com/ExaScience/arrow-street
  - toast0 3mo ago
    Thanks for explaining, I can see how it got to where it is.
deleted 3mo ago
[deleted]
mnw21cam 3mo ago
There was also an issue with Linux about 8 years ago where the THP daemon would start busy-looping searching for pages to amalgamate, wasting loads of CPU time (and I believe freezing the processes it was inspecting), and so people were advising switching off THP for that reason until it was fixed. It hit our large Java processes quite badly.