I think this is why it's not per-program: Say you have 16GB of RAM. You disable overcommit for your database, and you run it, and it allocates 14GB. But Chrome

I think this is why it's not per-program: Say you have 16GB of RAM. You disable overcommit for your database, and you run it, and it allocates 14GB. But Chrome has overcommit enabled (why are you running Chrome and a database on the same box? Dunno, never got an answer from that engineer...), and it happily allocates 23GB. Later, Chrome uses up all the available memory, and the database is sad. But it's not Chrome's fault, it didn't know it wasn't allowed to use it all up! So then you redesign overcommit so there's a "no-overcommit pool" with priority, and an "overcommit pool". You end up with only 2GB of overcommit pool for the kernel + userland + Chrome, so Chrome just gets killed early and often. Might as well have just disabled overcommit entirely, if random apps are going to die anyway. (Incidentally, cgroups allow setting soft and hard memory limits, so you can impose particular memory limits on arbitrary applications to have more determinism)