5 ms·

Slab would be part of main memory, not to be confused with swap. ~10% of the utilization on my system is slab. [bjames@lwks1 ~]$ grep "Slab\|MemTotal\|Active:

by sh-run 7y ago

Slab would be part of main memory, not to be confused with swap. ~10% of the utilization on my system is slab. [bjames@lwks1 ~]$ grep "Slab\|MemTotal\|Active:" /proc/meminfo MemTotal: 65976620 kB Active: 6139820 kB Slab: 605988 kB That's hardly insignificant. It sounds to me like slab allocation is specifically used to allocate small blocks of memory (less than a page). Ie a slab might be set aside for integers, then if an application (edit: not applications, see rayiner's comment below) needs to store an integer it gets stored in that slab instead of somewhere else in memory. I'm not a Linux developer, so I hope I'm not spreading bad info. Maybe someone else can chime in. I assume this would largely be short lived allocations so I can see where optimizations here would lead to power savings.

rayiner 7y ago
The slab allocator is for sub-page-size kernel objects. User space programs allocate entire virtual memory pages and use a different user-level allocator you allocate sub-page-size objects.
- yellowapple 7y ago
  Memory savings are still memory savings, whether they happen in kernel-space or user-space.
  - coryrc 7y ago
    Most memory usage is not in the kernel. It's not a big effect overall.
    - yellowapple 7y ago
      Per GGP's comment at least 605MB of memory is slab memory¹. That's around 25% (if not more) of the memory on an average smartphone. Apparently you disagree, but I'd call a reduction of that a pretty darn big effect. ¹ On my machine it's currently at only about 165MB, so not quite as extreme, but still a decent chunk of memory.
    - derefr 7y ago
      However, you kind of want most memory usage to be in the kernel. Having something happen entirely in kernelspace is always better than having half of it happen in userspace. sendfile(2), for example. To the degree that you can achieve "getting the kernel to do your work for you", the kernel memory allocator becomes one of the main determinants on your scaling requirements. IIRC WhatsApp hit this point with the FreeBSD kernel, and had to tune the heck out of the kernel to keep scaling. (Tangent: why is it that we hear a lot about bespoke unikernels, and a lot about entirely-in-userspace designs like Snabb, but nobody talks about entirely-in-kernelspace designs? Linux itself makes a pretty good "unikernel framework": just write your business logic as a kernel driver (in e.g. Rust), compile it into a monolithic kernel, and then run no userland whatsoever.)
      - yellowapple 7y ago
        Don't you need at least some degree of a userland for e.g. init? Unless there's some kernel configuration setting of which I'm not aware, it'll outright panic if there's no init process, and I'm reasonably sure that happens in userspace.
        derefr 7y ago
        Yeah. (Though, I mean, if you're writing a kernel driver, you're probably brave enough to go in and yank out the code that tries to exec the initramfs /init.) But, you can always write a five-line "trivial init" in C that just starts and then goes to sleep forever. If you didn't know, init processes don't have any special kernel-imposed requirements. You can run /bin/bash as init; this is what many distros' single-user rescue modes do! Or, if you're even lazier than that, I believe Busybox has a configuration wizard that allows you to just deselect all the features. That'd probably spit out a "trivial init" binary.
      - Matthias247 7y ago
        > However, you kind of want most memory usage to be in the kernel I disagree on that one. More memory in the Kernel mean more chances for going OOM, more fragmentation of kernel memory, and less isolation and stability. In the ideal case I would rather want the least possible amount of memory in the Kernel (and maybe have that all statically allocated) in order to maximize stability and determinism.
  - rayiner 7y ago
    I’m not saying it’s not significant. Just clarifying what the article is talking about.

by sh-run 7y ago

rayiner 7y ago

The slab allocator is for sub-page-size kernel objects. User space programs allocate entire virtual memory pages and use a different user-level allocator you allocate sub-page-size objects.

yellowapple 7y ago
Memory savings are still memory savings, whether they happen in kernel-space or user-space.
- coryrc 7y ago
  Most memory usage is not in the kernel. It's not a big effect overall.
  - yellowapple 7y ago
    Per GGP's comment at least 605MB of memory is slab memory¹. That's around 25% (if not more) of the memory on an average smartphone. Apparently you disagree, but I'd call a reduction of that a pretty darn big effect. ¹ On my machine it's currently at only about 165MB, so not quite as extreme, but still a decent chunk of memory.
  - derefr 7y ago
    However, you kind of want most memory usage to be in the kernel. Having something happen entirely in kernelspace is always better than having half of it happen in userspace. sendfile(2), for example. To the degree that you can achieve "getting the kernel to do your work for you", the kernel memory allocator becomes one of the main determinants on your scaling requirements. IIRC WhatsApp hit this point with the FreeBSD kernel, and had to tune the heck out of the kernel to keep scaling. (Tangent: why is it that we hear a lot about bespoke unikernels, and a lot about entirely-in-userspace designs like Snabb, but nobody talks about entirely-in-kernelspace designs? Linux itself makes a pretty good "unikernel framework": just write your business logic as a kernel driver (in e.g. Rust), compile it into a monolithic kernel, and then run no userland whatsoever.)
    - yellowapple 7y ago
      Don't you need at least some degree of a userland for e.g. init? Unless there's some kernel configuration setting of which I'm not aware, it'll outright panic if there's no init process, and I'm reasonably sure that happens in userspace.
      - derefr 7y ago
        Yeah. (Though, I mean, if you're writing a kernel driver, you're probably brave enough to go in and yank out the code that tries to exec the initramfs /init.) But, you can always write a five-line "trivial init" in C that just starts and then goes to sleep forever. If you didn't know, init processes don't have any special kernel-imposed requirements. You can run /bin/bash as init; this is what many distros' single-user rescue modes do! Or, if you're even lazier than that, I believe Busybox has a configuration wizard that allows you to just deselect all the features. That'd probably spit out a "trivial init" binary.
    - Matthias247 7y ago
      > However, you kind of want most memory usage to be in the kernel I disagree on that one. More memory in the Kernel mean more chances for going OOM, more fragmentation of kernel memory, and less isolation and stability. In the ideal case I would rather want the least possible amount of memory in the Kernel (and maybe have that all statically allocated) in order to maximize stability and determinism.
- rayiner 7y ago
  I’m not saying it’s not significant. Just clarifying what the article is talking about.