A new Linux memory controller promises to save lots of RAM(thenewstack.io)
thenewstack.io
A new Linux memory controller promises to save lots of RAM
https://thenewstack.io/a-new-linux-memory-controller-promises-to-save-lots-of-ram/
12 comments
Off-topic: it's too bad that The New Stack reproduced verbatim the term "Memory Controller" instead of "Memory Allocator" (as mm/slab.h agrees). I was really confused as to how there was going to be a Linux Memory Controller, and thought some new-fangled AMD/Intel memory controller thing had moved into software...
My first mental image was of an MMU that was running Linux internally—like the Xeon Phi, but even more ridiculous.
I've used a couple DMA controllers that are Turing complete-- it's pretty cool what kinds of things you can offload.
There’s a semi-wellknown trick on the raspberry pi for performing high-bandwidth and high-precision (in time) operations on GPIO pins from userland, using the DMA engine. You keep an in-memory buffer of the next few milliseconds of bit patterns you want to write to the memory-mapped GPIOs and then just leave the DMA engine endlessly copying data from this (circular) buffer into the GPIOs. But crucially, you “pace” the DMA transfer by configuring it to alternate between copying a word to the GPIOs and copying a word to some other peripheral that you’ve clocked at a specific rate (e.g. the audio DAC, which won’t acknowledge each write until it’s converted the previous one). This lets you define the state of the GPIOs as an arbitrary waveform sampled at some frequency of your choosing, which is a crazy powerful tool for e.g. motor control (that’s what the Printipi 3D printer does) or bitbanging communication protocols, etc.
You can also flip it around and sample GPIOs at close to 1 MHz. Piscope is an example of that. Once you start pushing 1 MHz, jitter starts to become nontrivial as you’re saturating the bus or competing with other memory transfers.
So yes: a capable DMA controller can do some pretty mind-blowing things!
You can also flip it around and sample GPIOs at close to 1 MHz. Piscope is an example of that. Once you start pushing 1 MHz, jitter starts to become nontrivial as you’re saturating the bus or competing with other memory transfers.
So yes: a capable DMA controller can do some pretty mind-blowing things!
Fyi, a simple microcontroller like stm32 which is like 3$ can push gpio at 25mhz reliably.
It’s true. And with the newer multicore Pi’s, you could probably get similar results just by pinning a thread to one core and dedicating that core to managing your IO. There are a million ways to solve any problem.
Perhaps the single biggest advantage of the DMA solution for something like pi-scope is that it means people who want to use the pi as a scope need only download a piece of software: no soldering or flashing of MCUs required. The initial setup is more beginner-friendly, with the drawback that contributing might be more intimidating because the software is doing more complex work.
Perhaps the single biggest advantage of the DMA solution for something like pi-scope is that it means people who want to use the pi as a scope need only download a piece of software: no soldering or flashing of MCUs required. The initial setup is more beginner-friendly, with the drawback that contributing might be more intimidating because the software is doing more complex work.
That sounds like an excellent start for a wavetable based synthesizer.
Reminds me of the ASICs in the Amiga.
Turing completeness means undecidability of termination, not something you'd enjoy in DMA operations!
Turing completeness does not mean you cannot reason about the termination (or performance) of any particular program.
It's not something you'd enjoy in most computer programs, but we still use Turing complete CPUs and Turing complete programming languages, because they're more flexible. No reason DMA needs to be different.
Most hardware will hang if you program it incorrectly, even if it isn't advertised as being turing-complete.
Turing completeness is a statement about the nature of infinity. It is always decidable if a Turing machine with a fixed upper bound on it's tape length will halt.
There was a post (this year?) mapping Godel's incompleteness theorem to the halting problem. I found it inspiring, not in the least because the link revealed they were both in fact statements about the properties of infinity - something that was not obvious by just looking at either problem on its own. It is of those few cases where the whole was obviously bigger than the sum of the parts, for me at least.
There was a post (this year?) mapping Godel's incompleteness theorem to the halting problem. I found it inspiring, not in the least because the link revealed they were both in fact statements about the properties of infinity - something that was not obvious by just looking at either problem on its own. It is of those few cases where the whole was obviously bigger than the sum of the parts, for me at least.
Yes, though Xeon Phi had a BSD :).
For those of us that don't know what the above is about: https://news.ycombinator.com/item?id=12293771
I thought it was an MMU designed to work with a specific Linux memory feature.
My first jump was some major change to the MM subsystem
Perhaps Memory Resource Controller is the best term? From the memory cgroup documentation [0]:
> NOTE: The Memory Resource Controller has generically been referred to as the memory controller in this document. Do not confuse memory controller used here with the memory controller that is used in hardware.
[0] https://www.kernel.org/doc/Documentation/cgroup-v1/memory.tx...
> NOTE: The Memory Resource Controller has generically been referred to as the memory controller in this document. Do not confuse memory controller used here with the memory controller that is used in hardware.
[0] https://www.kernel.org/doc/Documentation/cgroup-v1/memory.tx...
Programmable memory controllers might be really interesting, even if it was limited kind of programmability. You could have process specific policies like "don't pollute cache" or "real-time" or per-app tuned prefetch rules. Someone must have done this in academia...
I've been hoping for some time that someone could make an in-hardware (or FPGA) compressing memory controller or MMU, with low enough latency to be comparable to memory access, possibly even higher bandwidth (being compressed), and transparent. Would increase the effective memory of SoCs, but also in general. Thinking like zram but realtime. Another one for academia I guess.
Basically a hardware lookup table, right? Potentially fast to read, but impossibly slow to write as you’d need to reprogram an FPGA. Still a cool concept.
I had in mind something like several parallel hardware LZ codecs sitting at the border between the CPU caches and memory, along with some VM driver software. Given CPU writes would go to caches first (as managed by cache-coherency logic), they would remain fast to read, only at the point a flush is triggered would a codec have to write a compressed page to memory - which may be slower than uncompressed. I'd imagine there would need to be a bunch of experimental work to determine page size and other parameters, which may even be application-specific tunables.
There is one specialized area this is widely done in: hw texture compression in GPUs. Buts it's read only and not automatic.
GPUs also do lossless transparent compression in some places for bandwidth reduction, at the cost of allocating some additional metadata. It's commonly called delta color compression. (And it doesn't reduce memory allocations, but it fits the theme here.)
You might be interested in the programmable prefetcher work from Sam Ainsworth at Cambridge University https://www.cl.cam.ac.uk/~sa614/papers/programmableprefetche...
I've taken a brief read through the patch series. It's a noble effort, but from the light initial feedback there will a few rounds of rework before this is a candidate in a release. This also feels unlikely to be backported, given the numerous subtle changes (e.g. cgroups v1 incompatibilities, byte vs. page accounting).
This really seems like a somewhat obvious caveat of SLUB, in hindsight at least, given how memory cgroups work. The accounting overhead here seems like opening a complexity can of worms.
For memory-pressure intensive short-lived applications (e.g. Hadoop jobs with no strict NUMA affinity), this could net some real benefits when processes jump across cores, let alone physical cores.
Most serious folks should be setting at least some CPU affinity anyways and discourage the scheduler from bouncing processes between cores, which otherwise exasperates the issue mitigated by this patch set.
If you've ever wondered why you struggle to make use of all of your RAM on a large many-core host, this is potentially a big reason why.
This really seems like a somewhat obvious caveat of SLUB, in hindsight at least, given how memory cgroups work. The accounting overhead here seems like opening a complexity can of worms.
For memory-pressure intensive short-lived applications (e.g. Hadoop jobs with no strict NUMA affinity), this could net some real benefits when processes jump across cores, let alone physical cores.
Most serious folks should be setting at least some CPU affinity anyways and discourage the scheduler from bouncing processes between cores, which otherwise exasperates the issue mitigated by this patch set.
If you've ever wondered why you struggle to make use of all of your RAM on a large many-core host, this is potentially a big reason why.
> exasperates
exacerbates? :)
exacerbates? :)
> With this new controller, it’s possible to gain anywhere from 35-42% better memory usage in Linux.
Considering the gain I'm surprised there wasn't more discussion or interest in this.
Considering the gain I'm surprised there wasn't more discussion or interest in this.
It is apparently only slab memory usage, not main memory usage.
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.
~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.
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.
Memory savings are still memory savings, whether they happen in kernel-space or user-space.
Most memory usage is not in the kernel. It's not a big effect overall.
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.)
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.)
> 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.
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.
But what’s the difference between in stability between an autoscaling+autohealing VM running a 100% kernel-mode application, and a VM hosting a 100% user-mode process (presumably under an init daemon that will autoheal it)?
And does “fragmenting kernel memory” mean anything, if you preallocate a memory arena in your kernel driver (taking “everything the base kernel isn’t using”, like a VM memory-balloon driver), and then plop a library like jemalloc into the kernel to turn the arena into your driver’s shiny new in-kernel heap? You’re not messing with the kernel’s own allocation tables, any more than a KVM VM’s TLB interfere’s with the dom0 kernel’s TLB.
See also: capability-based operating systems (like Microsoft’s ill-fated Midori), where there’s no such thing as a per-process address space, just one big shared heap where processes can touch any physical memory, but only through handles they own and cannot forge. If your OS has exactly one process anyway, you don’t even need the capabilities. (This also being how managed-runtime unikernels like Erlang-on-Xen work.)
Also, another example of what I’m talking about re: benefits of this approach. would you rather that a VM operating as an iSCSI disk server ran as a userland iSCSI daemon managing kernel block devices; or—as it is currently—as an entirely in-kernel daemon that can manage and serve block devices with no context switches or memory copies required?
And does “fragmenting kernel memory” mean anything, if you preallocate a memory arena in your kernel driver (taking “everything the base kernel isn’t using”, like a VM memory-balloon driver), and then plop a library like jemalloc into the kernel to turn the arena into your driver’s shiny new in-kernel heap? You’re not messing with the kernel’s own allocation tables, any more than a KVM VM’s TLB interfere’s with the dom0 kernel’s TLB.
See also: capability-based operating systems (like Microsoft’s ill-fated Midori), where there’s no such thing as a per-process address space, just one big shared heap where processes can touch any physical memory, but only through handles they own and cannot forge. If your OS has exactly one process anyway, you don’t even need the capabilities. (This also being how managed-runtime unikernels like Erlang-on-Xen work.)
Also, another example of what I’m talking about re: benefits of this approach. would you rather that a VM operating as an iSCSI disk server ran as a userland iSCSI daemon managing kernel block devices; or—as it is currently—as an entirely in-kernel daemon that can manage and serve block devices with no context switches or memory copies required?
> But what’s the difference between in stability between an autoscaling+autohealing VM running a 100% kernel-mode application, and a VM hosting a 100% user-mode process (presumably under an init daemon that will autoheal it)?
Running everything (or as much as possible) in Kernel mode has obvious performance benefits, hard to argue against that.
The counter-argument isn't about performance, it's about flexibility. As far as I'm aware, no major cloud providers allow you to run apps in Kernel mode. So if you develop an app on your own hardware, but may eventually deploy it in the cloud, you better put everything in user mode. If you want to switch from one cloud provider to another, it's (relatively) easy if everything is in kernel mode.
Also, while running in Kernel mode is almost certainly faster than user mode, it's probably not that much faster. If your app relies on the network or is heavy on disk I/O, that's where your bottleneck will be, not OS user/kenel mode switching.
In short, running things in Kernel mode may sometimes be a good performance decision, but it's often a bad business decision.
Running everything (or as much as possible) in Kernel mode has obvious performance benefits, hard to argue against that.
The counter-argument isn't about performance, it's about flexibility. As far as I'm aware, no major cloud providers allow you to run apps in Kernel mode. So if you develop an app on your own hardware, but may eventually deploy it in the cloud, you better put everything in user mode. If you want to switch from one cloud provider to another, it's (relatively) easy if everything is in kernel mode.
Also, while running in Kernel mode is almost certainly faster than user mode, it's probably not that much faster. If your app relies on the network or is heavy on disk I/O, that's where your bottleneck will be, not OS user/kenel mode switching.
In short, running things in Kernel mode may sometimes be a good performance decision, but it's often a bad business decision.
I’m confused on what you mean by cloud providers not allowing you to run “in kernel mode.” I know for sure that both MirageOS and Erlang-on-Xen (unikernels) can be easily deployed as AWS AMIs. And even on compute providers less friendly to custom image booting (like DigitalOcean), you can always bootstrap off of a standardized Linux image by just telling it to fetch and kexec(2) your custom kernel binary in the instance’s cloud-init script.
> I know for sure that both MirageOS and Erlang-on-Xen (unikernels) can be easily deployed as AWS AMIs.
I’m not familiar with this particular deployment process, so don’t want to speak out of line... but this being the internet, why not.
I’m a bit skeptical that Amazon would let you run anything in pure kernel mode, it’s likely a VM/ sandbox wrapping an OS that’s operating in Kernel mode, likely negating much of the performance benefits.
Second, you mentioned two specific images, and I’ll assume they work fine on AWS, but they are just two, and if your working with them, you probably have very specific needs, not suitable for general development.
Third, who knows if these images will work on other cloud providers. Once you get your kernel mode app working on one, your locked in.
Fourth, what are you doing that requires this level of local machine performance operating in the cloud? It’s probably almost always better to invest your optimization time/dollers elsewhere.
Fifth, if this was a good / easy idea, many people would be doing it, but they aren’t. Either you’ve stumbled upon some secret enlightened approach, or your probably wron.
I’m not familiar with this particular deployment process, so don’t want to speak out of line... but this being the internet, why not.
I’m a bit skeptical that Amazon would let you run anything in pure kernel mode, it’s likely a VM/ sandbox wrapping an OS that’s operating in Kernel mode, likely negating much of the performance benefits.
Second, you mentioned two specific images, and I’ll assume they work fine on AWS, but they are just two, and if your working with them, you probably have very specific needs, not suitable for general development.
Third, who knows if these images will work on other cloud providers. Once you get your kernel mode app working on one, your locked in.
Fourth, what are you doing that requires this level of local machine performance operating in the cloud? It’s probably almost always better to invest your optimization time/dollers elsewhere.
Fifth, if this was a good / easy idea, many people would be doing it, but they aren’t. Either you’ve stumbled upon some secret enlightened approach, or your probably wron.
> 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.
A while back, I worked for an embedded systems company that developed real-time OSes, compilers, and debuggers. Everything in the Kernel had to be statically allocated, malloc was simply not allowed. Even user-land programs, which could dynamically allocate memory, had to check the return value of malloc to make sure the memory was actually allocated (malloc returns null if it can't allocate memory).
It was painful to program in this environment, but over time, I grew to love it. Software developers did not feel like they were developing "Soft"-ware; memory, CPU, I/O, interrupts, and even heat dissipation were not infinite resources you could use without care. These restrictions elevated the development process, and made the "developers" feel more like "engineers".
A while back, I worked for an embedded systems company that developed real-time OSes, compilers, and debuggers. Everything in the Kernel had to be statically allocated, malloc was simply not allowed. Even user-land programs, which could dynamically allocate memory, had to check the return value of malloc to make sure the memory was actually allocated (malloc returns null if it can't allocate memory).
It was painful to program in this environment, but over time, I grew to love it. Software developers did not feel like they were developing "Soft"-ware; memory, CPU, I/O, interrupts, and even heat dissipation were not infinite resources you could use without care. These restrictions elevated the development process, and made the "developers" feel more like "engineers".
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.
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.
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.
[deleted]
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.
¹ On my machine it's currently at only about 165MB, so not quite as extreme, but still a decent chunk of memory.
I’m not saying it’s not significant. Just clarifying what the article is talking about.
This article is so full of Linux jargon, it’s impossible to follow unless you’re deeply steeped in it. Is there another source? Memory controllers have been developed for 30+ years, I’m surprised and slightly skeptical there are still major breakthroughs, would love to read an explanation that I can actually understand.
I randomly stumbled blindly into the world of slab allocation and wrote a little bit about it here: https://blog.mclemon.io/discover-a-linux-utility-slabtop
That might help at least with the slab part.
That might help at least with the slab part.
The optimization is primarily aimed at systems with multiple cgroups, so think Docker-like container platforms.
Traditional servers should be positively effected as well [1].
> Also, there is nothing fb-specific. You can take any new modern distributive (I've tried Fedora 30), boot it up and look at the amount of slab memory. Numbers are roughly the same.
The explanation given in the article is that most distributions with systemd spin up a bunch of cgroups even without a container-oriented workload.
[1]: https://lkml.org/lkml/2019/9/19/628
> Also, there is nothing fb-specific. You can take any new modern distributive (I've tried Fedora 30), boot it up and look at the amount of slab memory. Numbers are roughly the same.
The explanation given in the article is that most distributions with systemd spin up a bunch of cgroups even without a container-oriented workload.
[1]: https://lkml.org/lkml/2019/9/19/628
This is correct. Looks like they're proposing to share memory slabs across cgroups. But cgroups being a mechanism that's meant to partition groups of tasks for resource control, I don't know how wise it is to have them share memory slabs.
> much-improved memory utilization between multiple memory cgroups
There will be no improvement if I don't use memory cgroups, which means it's not related to a typical desktop or server without containers. But still good news, the use of containers can only expand.
There will be no improvement if I don't use memory cgroups, which means it's not related to a typical desktop or server without containers. But still good news, the use of containers can only expand.
Systemd uses cgroups heavily, so chances are your typical distribution runs hundreds of them under the hood.
Thanks for reminding me about systemd. I just used "systemd-cgtop", and yes, I see 38 cgroups, one cgroup for each service/user. But 88% of the memory is used by one cgroup: user.slice, for all the program started by me under the desktop. So I'm not sure it can save a lot of memory on container-less desktop.
Surely good for all servers.
Surely good for all servers.
Not familiar with this, but I assume measures are taken so that we don’t accidentally share memory content between different processes through slabs? That seems a pretty straight forward security consideration.
Kind of interesting to think how much money/energy this can save across the planet
Seems like near zero.
RAM is specced based on worse case, generally - and it's not like this is going to save that much anyway since it's not user-space memory.
RAM is specced based on worse case, generally - and it's not like this is going to save that much anyway since it's not user-space memory.
Unused RAM usually is utilized for filesystem caches. So more cache, less disk usage, less power usage. Though difference must be truly negligible. Those trends of computing ecology terrifying me. People are talking about truly insignificant things. Yes, at large scale even 0.001% of energy saving seems like a significant number. But large scale is planetary scale and now on that scale it's again rounding error.
If you want to save energy, do everything you can to kill cryptocurrency. Now THAT is some obscene waste of energy.
I wonder how much impact would uninstalling social apps from smartphones have. Getting rid of FB, TW, WA clients pooling made my phone run for 2 days without charging vs 1 previously. Now at 1 billion users scale...
Well, the Jevons paradox would probably apply to any significant gains: https://en.wikipedia.org/wiki/Jevons_paradox
it's definitely not zero. if you have a million machines in your data centers then it easily adds up to something quantifiable.
I wonder if these improvements will trickle down to desktop Linux users.
Basically if it is accepted into the mainline kernel then yes, otherwise not unless people decide to install custom kernels. Distros backport a little bit, but generally don't include anything not accepted into mainline. Then there are a few popular custom kernels that include changes not included in mainline because they are not generally useful, and only make sense for specific workloads.
Likely immediately for HEDT owners.
I make use of VFIO on my home Threadripper, and while it's "only" 12 cores and 64GB RAM, it's NUMA so I have to use thread pinning to keep cores on the same die so they're not reaching across the Infinity Fabric to the other memory controllers.
With better memory allocation, I could assign >12 vCPUs on performance oriented VMs or use more than half my memory without incurring a latency penalty.
I make use of VFIO on my home Threadripper, and while it's "only" 12 cores and 64GB RAM, it's NUMA so I have to use thread pinning to keep cores on the same die so they're not reaching across the Infinity Fabric to the other memory controllers.
With better memory allocation, I could assign >12 vCPUs on performance oriented VMs or use more than half my memory without incurring a latency penalty.
So they are sharing common code segments like libraries? I hope this has some code/data awareness.
It sounds like it sticks kernel objects if the same type in one big pool, whereas they used to have per container pools. That'd lead to better utilization and probably better caching behavior too although that's not explicitly stated.
The big challenge would be making sure that the different containers' resource limits are respected, but it looks like they're addressing that head on.
The big challenge would be making sure that the different containers' resource limits are respected, but it looks like they're addressing that head on.
Security isn't as important as performance.
Is this a serious comment? I'm genuinely uncertain whether you mean this seriously.
Not the person you asked that, but yeah, personally i also find performance more important than security for my personal computer. The chances of me being attacked are practically zero (theoretical attacks do not count, most of these security issues you read focus on the possibility and totally ignore probability) while the chances of me wanting my computer to be faster are 100%. I hate waiting for my computer to do things.
Note BTW that there is a difference between "i find performance more important" and "i do not care about security at all". I do care about security, but i am not willing to sacrifice my computer's performance for it. I simply consider performance more important.
Note BTW that there is a difference between "i find performance more important" and "i do not care about security at all". I do care about security, but i am not willing to sacrifice my computer's performance for it. I simply consider performance more important.
>the chances of me being attacked are practically zero
That's because the OS developers have placed value on security over performance. Whooping cough is rare too, we still vaccinate against it.
If you want a classic example, bounds checking an array is important to avoid RCE and sandbox escape attempts. It can also have a hefty performance penalty, under some scenarios it trashes the branch predictor/instruction pipeline. But I'm glad that my browser isn't as fast as machine-ly possible when streaming video, because I'd prefer if there wasn't a risk of having my emails from various banks, stored passwords in the browser, etc from being collected and sent to a bad actor.
That's because the OS developers have placed value on security over performance. Whooping cough is rare too, we still vaccinate against it.
If you want a classic example, bounds checking an array is important to avoid RCE and sandbox escape attempts. It can also have a hefty performance penalty, under some scenarios it trashes the branch predictor/instruction pipeline. But I'm glad that my browser isn't as fast as machine-ly possible when streaming video, because I'd prefer if there wasn't a risk of having my emails from various banks, stored passwords in the browser, etc from being collected and sent to a bad actor.
> That's because the OS developers have placed value on security over performance.
No, that is mainly because nobody knows nor cares about me personally.
As for your example, i already addressed it with that last part in my message:
> Note BTW that there is a difference between "i find performance more important" and "i do not care about security at all". I do care about security, but i am not willing to sacrifice my computer's performance for it. I simply consider performance more important.
The browser is a case where i'd accept less performance for better security because it is the primary way where things can get into my computer outside of my control. However that doesn't mean i'd accept less performance in, e.g., my image editor, 3d renderer, video encoder or whatever else.
In other words, i want my computer to be reasonably secure, just not at all costs.
No, that is mainly because nobody knows nor cares about me personally.
As for your example, i already addressed it with that last part in my message:
> Note BTW that there is a difference between "i find performance more important" and "i do not care about security at all". I do care about security, but i am not willing to sacrifice my computer's performance for it. I simply consider performance more important.
The browser is a case where i'd accept less performance for better security because it is the primary way where things can get into my computer outside of my control. However that doesn't mean i'd accept less performance in, e.g., my image editor, 3d renderer, video encoder or whatever else.
In other words, i want my computer to be reasonably secure, just not at all costs.
> No, that is mainly because nobody knows nor cares about me personally.
I mean, they do care about you. I assume you have a bank account, or personal information that can be used to open a credit card under your name?
> However that doesn't mean i'd accept less performance in, e.g., my image editor, 3d renderer, video encoder or whatever else.
Most of that is specifically designed with security in mind. For instance the GPU has it's own MMU so you can't use it to break the boundaries between user mode and kernel mode.
I mean, they do care about you. I assume you have a bank account, or personal information that can be used to open a credit card under your name?
> However that doesn't mean i'd accept less performance in, e.g., my image editor, 3d renderer, video encoder or whatever else.
Most of that is specifically designed with security in mind. For instance the GPU has it's own MMU so you can't use it to break the boundaries between user mode and kernel mode.
> I mean, they do care about you. I assume you have a bank account, or personal information that can be used to open a credit card under your name?
That is not caring about me though. Honestly at that point you are spreading the same sort of hand-wavy FUD that is used to take away user control "because security".
> Most of that is specifically designed with security in mind. For instance the GPU has it's own MMU so you can't use it to break the boundaries between user mode and kernel mode.
Again, i'm not talking about not having security at all.
That is not caring about me though. Honestly at that point you are spreading the same sort of hand-wavy FUD that is used to take away user control "because security".
> Most of that is specifically designed with security in mind. For instance the GPU has it's own MMU so you can't use it to break the boundaries between user mode and kernel mode.
Again, i'm not talking about not having security at all.
> That is not caring about me though. Honestly at that point you are spreading the same sort of hand-wavy FUD that is used to take away user control "because security".
I legitimately don't understand your argument here. Do you not lock your car? A opportunistic car thief doesn't have to "care about you", and going through the process of unlocking your car could slow you down.
I legitimately don't understand your argument here. Do you not lock your car? A opportunistic car thief doesn't have to "care about you", and going through the process of unlocking your car could slow you down.
Those comparisons miss important details so they aren't helpful - and also i do not have a car. Though if you want a comparison that does apply to me - i lock my apartment's door, though i do not bother with installing a metal door and window bars despite knowing how easy the door would be to break for someone who insists in entering my place as the chances of this happening are simply not worth the cost.
I already repeated that several times, i'm not sure how else to convey it: i care about security (lock my door), but it isn't at the top of my priorities (do not have a metal door and window bars).
I already repeated that several times, i'm not sure how else to convey it: i care about security (lock my door), but it isn't at the top of my priorities (do not have a metal door and window bars).
The problem is you're speaking in metaphors. Which security is getting in your way that you can't trivially disable?
It kinda depends on the context. If your machine isn’t on the internet and is dedicated to running like a large computational fluid dynamics simulation or something, security isn’t as much of an issue because there is no untrusted code running on the machine and there’s no way for hackers to access it. If your machine is Google’s public DNS server, security is critical.
> If your machine isn’t on the internet
I don't think there are many such machines anymore. I am not seeing this as a common case at all. And in the present context of the Linux memory controller, they would never sacrifice general kernel security for performance.
I don't think there are many such machines anymore. I am not seeing this as a common case at all. And in the present context of the Linux memory controller, they would never sacrifice general kernel security for performance.
Outside of your bubble they are pretty relevant. Hell, the biggest computers in the work generally run Linux without an internet connection.
And they are usually LAN connected thus Stuxnet-like worm infected laptop can still cause a damage. Security is always important.
Fun of you to assume my bubble. What are these biggest computers that you refer to that are not connected to the internet?
Scientific supercomputers used for academic and industry needs. Eg. weather prediction, CFD and FEM simulations, image processing, deep learning, and much more.
When I'm concerned about security, I run an OS that is not Linux. When there's nothing critical on a system (from a security perspective), I run Linux. Why would I care if someone hacks my machine and gets my browsing history? Half the companies in SV already have it.
What's the point when we can just download more RAM?
"it could find its way into the mainline kernel as early as 2020"
Gosh. So soon?
Gosh. So soon?
I'm not a kernel dev, but this looks like a pretty big change to a critical system, with very diverse non-trivial effects on performance depending on workloads.
It needs to be properly reviewed and tested before landing, and that takes time.
It needs to be properly reviewed and tested before landing, and that takes time.