5 ms·

People never learn. News at eleven. Just the other day was reading N. Wirth objecting on using a resource lavishly just because it was cheap. And just now, in

People never learn. News at eleven. Just the other day was reading N. Wirth objecting on using a resource lavishly just because it was cheap. And just now, in the same front page of HN, some guy wants programmers to stop calling themselves engineers because they aren't. Well, let's build a bridge using all the iron we can get our hands on (iron is very cheap you know); or even better, let's use all the RAM in the computer with this program of ours.

0xcde4c3db 10y ago
It's also a lot of fun when someone gets the bright idea of "oh, we'll allocate until we have 75% of RAM and then stop; that will keep us from swapping". Which isn't so terrible until somebody installs a second program using that strategy.
- crististm 10y ago
  My favourite these days is Linux OOM killer. For some people it's just right to randomly kill a process instead of rejecting the current request. My mind gets a blue-screen every time I'm contemplating this issu.,....ds.fsd... :) edit: https://discuss.96boards.org/t/yocto/576 https://discuss.96boards.org/t/yocto/576
  - SomeStupidPoint 10y ago
    Wait, what? Memory allocation "doesn't fail" so they kill a random program? Can someone link me to an explanation of this?
    - cturner 10y ago
      "Memory allocation "doesn't fail"" That's not quite it. But it does deserve a double-take. When you request memory, it generally works out fine. But it doesn't actually give you a lock on the pages you need until you request those pages. This leads to weird situations where memory is oversubscribed. When this happens the OS casts one of your processes into the rift. Google for "oom killer". To me this sounds insane - a basic breach in the contract of malloc. However, it's possible that this is one of those situations that involves a complex tradeoff that you won't grok until you've been the guy building it. It would be interesting to know what other OSs do. Something that is annoying: as far as I know there is no signal that fires when this happens. Instead, you scrape logs to learn about it. Whereupon you will reboot the box, because you no longer trust its state. You can get a callback when this happens if you use systemtap. In practice it's less of a problem than you'd think. If you care about the thing you're building, you will have made it host-independent. From the perspective of production software, there's no difference between a rifted process and a motherboard death. If you're using sockets as your IPC mechanism, it doesn't matter why the process died, just that it did.
      - mikeash 10y ago
        To elaborate a bit, there are basically three ways to do this stuff. One is to commit memory on request. If all of your RAM and swap is committed, then malloc will fail. This is probably how we expect it to work, but it can be really wasteful. Some programs will malloc a huge area and only use a small portion of it, and in this scheme, that memory is "in use." It's also worth noting that most programs don't tolerate malloc failure well at all, and will just crash anyway. Another way is to overcommit, where malloc doesn't actually reserve memory initially but only on first use, but only pause processes when memory fills up. If a process needs more memory and there isn't any more available, that process blocks until more memory becomes available. This means nobody gets killed, but it's not uncommon for the system to just deadlock like this forever once memory fills up. And the third way is as you describe, to overcommit and kill processes when you run out of memory. Note that there's no right answer, just different tradeoffs. Linux lets you configure this to an extent as well, so if you don't like the default, you can change it!
        gcr 10y ago
        After a fork, does the amount of committed memory increase by the size of the child's allocated virtual memory space? I'm curious how committed memory interacts with COW fork semantics. After all, a child can just overwrite the COW/copy of the memory it inherited from its parent without allocating anything else.
        haldean 10y ago
        No, all of the child's memory mappings are shared with its parent. Upon write, though, that becomes a new committed mapping; I believe the entire page is copied, so you could end up committing another 4k with a one-byte write from the child.
        gcr 10y ago
        Hm. Then suppose I turn off the OOM killer. What happens to a process that writes to its parent's page if the system has no memory left to commit?
  - dom0 10y ago
    For Linux systems in (heavy) interactive use early-oom is a must have, pretty much regardless of how much memory you have.
dom0 10y ago
To be fair, the MM primitives that we have today are the same we had in 1979, while the capabilities of the hardware evolved, and the actual needs evolved, too. For example, caching. It's essentially impossible to do caching at the application layer right unless your cache is also persistent with no durability or consistency needs whatsoever and can be mmaped (and you don't mind total I/O trashage). The persistence part also implies that you must be able to store the entire cache somewhere. What an application would want here is a mechanism to allocate cache memory that the kernel can throw away, if need be, and notify the application of that, so that the app can adjust. That's not impossible to do, it's just tricky - and beyond POSIX.
mikeash 10y ago
I'm pretty sure "real" engineers would be very much in favor of using a cheap resource lavishly, if the tradeoff is worth it. Adding a million dollars to the design cost in order to save $100,000 in resource costs isn't a good idea, and a good engineer will design accordingly. The difference is that engineers have codified this and call it "safety factor." Your house is built to carry perhaps ten times the load it truly needs to, because it's cheaper to throw in extra materials than it is to build it to hold precisely what it needs. An airplane is built with much thinner margins, because saving materials is far more valuable, and it's well worth the extra time and attention to.
- tedunangst 10y ago
  I suppose that works with RAM and CPU waste, but I notice the people building gigabyte consuming irc clients aren't paying for all their users RAM, so the cost tradeoff is rather different.
- crististm 10y ago
  Look up Hamming's course on "Learning to learn". An optimal design is not robust. You add a safety factor and this addition is wasteful in some sense (thus not optimal) and necessary in another. Do you design a building so that the toilets are optimally used? Likewise for planes. But just because you have enough of a cheap resource (RAM) it is not a given that using it in excess is either optimal or robust.
  - TeMPOraL 10y ago
    Also, most users aren't really aware what's using up the resources - only that their computer gets slower with time. I actually wish Windows would start naming & shaming applications - e.g. by showing a balloon when the system slows down, that would say that application X and Y are consuming most of the resources. As it is now, CPU, RAM and storage usage are perfect externalities for developers. The result of their abuse is user frustration, and reduction of the number of things people can do on their computers. That, and wasting user time. Unfortunately, there's no way that would make the developers suffer costs for wasting user's resources, so the only thing that lets us have lean software is engineering competence and human decency (both of which seem to be in short supply).

0xcde4c3db 10y ago

It's also a lot of fun when someone gets the bright idea of "oh, we'll allocate until we have 75% of RAM and then stop; that will keep us from swapping". Which isn't so terrible until somebody installs a second program using that strategy.

crististm 10y ago
My favourite these days is Linux OOM killer. For some people it's just right to randomly kill a process instead of rejecting the current request. My mind gets a blue-screen every time I'm contemplating this issu.,....ds.fsd... :) edit: https://discuss.96boards.org/t/yocto/576 https://discuss.96boards.org/t/yocto/576
- SomeStupidPoint 10y ago
  Wait, what? Memory allocation "doesn't fail" so they kill a random program? Can someone link me to an explanation of this?
  - cturner 10y ago
    "Memory allocation "doesn't fail"" That's not quite it. But it does deserve a double-take. When you request memory, it generally works out fine. But it doesn't actually give you a lock on the pages you need until you request those pages. This leads to weird situations where memory is oversubscribed. When this happens the OS casts one of your processes into the rift. Google for "oom killer". To me this sounds insane - a basic breach in the contract of malloc. However, it's possible that this is one of those situations that involves a complex tradeoff that you won't grok until you've been the guy building it. It would be interesting to know what other OSs do. Something that is annoying: as far as I know there is no signal that fires when this happens. Instead, you scrape logs to learn about it. Whereupon you will reboot the box, because you no longer trust its state. You can get a callback when this happens if you use systemtap. In practice it's less of a problem than you'd think. If you care about the thing you're building, you will have made it host-independent. From the perspective of production software, there's no difference between a rifted process and a motherboard death. If you're using sockets as your IPC mechanism, it doesn't matter why the process died, just that it did.
    - mikeash 10y ago
      To elaborate a bit, there are basically three ways to do this stuff. One is to commit memory on request. If all of your RAM and swap is committed, then malloc will fail. This is probably how we expect it to work, but it can be really wasteful. Some programs will malloc a huge area and only use a small portion of it, and in this scheme, that memory is "in use." It's also worth noting that most programs don't tolerate malloc failure well at all, and will just crash anyway. Another way is to overcommit, where malloc doesn't actually reserve memory initially but only on first use, but only pause processes when memory fills up. If a process needs more memory and there isn't any more available, that process blocks until more memory becomes available. This means nobody gets killed, but it's not uncommon for the system to just deadlock like this forever once memory fills up. And the third way is as you describe, to overcommit and kill processes when you run out of memory. Note that there's no right answer, just different tradeoffs. Linux lets you configure this to an extent as well, so if you don't like the default, you can change it!
      - gcr 10y ago
        After a fork, does the amount of committed memory increase by the size of the child's allocated virtual memory space? I'm curious how committed memory interacts with COW fork semantics. After all, a child can just overwrite the COW/copy of the memory it inherited from its parent without allocating anything else.
        haldean 10y ago
        No, all of the child's memory mappings are shared with its parent. Upon write, though, that becomes a new committed mapping; I believe the entire page is copied, so you could end up committing another 4k with a one-byte write from the child.
        gcr 10y ago
        Hm. Then suppose I turn off the OOM killer. What happens to a process that writes to its parent's page if the system has no memory left to commit?
- dom0 10y ago
  For Linux systems in (heavy) interactive use early-oom is a must have, pretty much regardless of how much memory you have.

dom0 10y ago

To be fair, the MM primitives that we have today are the same we had in 1979, while the capabilities of the hardware evolved, and the actual needs evolved, too. For example, caching. It's essentially impossible to do caching at the application layer right unless your cache is also persistent with no durability or consistency needs whatsoever and can be mmaped (and you don't mind total I/O trashage). The persistence part also implies that you must be able to store the entire cache somewhere. What an application would want here is a mechanism to allocate cache memory that the kernel can throw away, if need be, and notify the application of that, so that the app can adjust. That's not impossible to do, it's just tricky - and beyond POSIX.

mikeash 10y ago

I'm pretty sure "real" engineers would be very much in favor of using a cheap resource lavishly, if the tradeoff is worth it. Adding a million dollars to the design cost in order to save $100,000 in resource costs isn't a good idea, and a good engineer will design accordingly. The difference is that engineers have codified this and call it "safety factor." Your house is built to carry perhaps ten times the load it truly needs to, because it's cheaper to throw in extra materials than it is to build it to hold precisely what it needs. An airplane is built with much thinner margins, because saving materials is far more valuable, and it's well worth the extra time and attention to.

tedunangst 10y ago
I suppose that works with RAM and CPU waste, but I notice the people building gigabyte consuming irc clients aren't paying for all their users RAM, so the cost tradeoff is rather different.
crististm 10y ago
Look up Hamming's course on "Learning to learn". An optimal design is not robust. You add a safety factor and this addition is wasteful in some sense (thus not optimal) and necessary in another. Do you design a building so that the toilets are optimally used? Likewise for planes. But just because you have enough of a cheap resource (RAM) it is not a given that using it in excess is either optimal or robust.
- TeMPOraL 10y ago
  Also, most users aren't really aware what's using up the resources - only that their computer gets slower with time. I actually wish Windows would start naming & shaming applications - e.g. by showing a balloon when the system slows down, that would say that application X and Y are consuming most of the resources. As it is now, CPU, RAM and storage usage are perfect externalities for developers. The result of their abuse is user frustration, and reduction of the number of things people can do on their computers. That, and wasting user time. Unfortunately, there's no way that would make the developers suffer costs for wasting user's resources, so the only thing that lets us have lean software is engineering competence and human decency (both of which seem to be in short supply).