Linus also said Linux (kernel) is bloated: http://www.theregister.co.uk/2009/09..._bloated_huge/
Announcement
Collapse
No announcement yet.
OpenBSD 5.1 Released
Collapse
X
-
Originally posted by LightBit View PostI guess that was rhetorical answer then.
I tried and it seems you are right. Documentation is a bit confusing.
Is there any way to limit memory usage per process?
Yes, that is a problem. I prefer POSIX way, but that is subjective.
POSIX is accepted as standard by many OSes.
Comment
-
Originally posted by LightBit View PostLinus also said Linux (kernel) is bloated: http://www.theregister.co.uk/2009/09..._bloated_huge/
Comment
-
Originally posted by kraftman View PostStill, the features and completeness can make a difference.
Statically linked and striped "hello world" (only puts() used) binary.
Arch Linux: 737.2KB
OpenBSD: 83.1KB
I'm not sure if this is only because of glibc. It might be because of virtual library "linux-vdso.so". It doesn't matter anyway.
Comment
-
Originally posted by kraftman View PostDocumentation says "don't overcommit", so it doesn't sound so confusing to me. I never set any limits for processes, but maybe ulimit is what you are looking for.
It doesn't mention free or available RAM.
Originally posted by kraftman View PostLinux and OpenBSD are mostly POSIX compliant, but there are situations where POSIX says nothing and Linux (and probably BSD) has to do things on its own. The one I remember had to do something with real time and scheduling.
Comment
-
Originally posted by LightBit View PostThis part: "The total address space commit for the system is not permitted to exceed swap + a configurable percentage (default is 50) of physical RAM"
It doesn't mention free or available RAM.
Yes, but they try to be as much as possible. Of course there are some missing parts.
Comment
-
Originally posted by LightBit View PostI don't think this are only feautures:
Statically linked and striped "hello world" (only puts() used) binary.
Arch Linux: 737.2KB
OpenBSD: 83.1KB
I'm not sure if this is only because of glibc. It might be because of virtual library "linux-vdso.so". It doesn't matter anyway.
and here:
Last edited by kraftman; 07 May 2012, 04:10 AM.
Comment
-
Originally posted by kraftman View Post"The total address space commit for the system is not permitted to exceed swap + a configurable percentage (default is 50) of physical RAM." It does mean it won't exceed your physical memory (RAM + swap), so it won't overcommit. It simply can't exceed the free memory and not exceed RAM + swap same time. When you have 2GB of RAM and only 1GB is free then it can't allocate more than 1GB, because it will overcommit.
Originally posted by kraftman View PostI think it's better to be mostly rather than full POSIX compliant. If you are mostly compliant you overcommit POSIX limits. Full POSIX compliant are some of the legacy systems.
Comment
-
Originally posted by kraftman View Post
Comment
Comment