Announcement

Collapse
No announcement yet.

OpenBSD 5.1 Released

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #91
    Linus also said Linux (kernel) is bloated: http://www.theregister.co.uk/2009/09..._bloated_huge/

    Comment


    • #92
      Originally posted by LightBit View Post
      libc.so (amd64, strip -s):
      Arch Linux: 1.7MB
      OpenBSD: 793.6KB

      Possible, but hard.
      Still, the features and completeness can make a difference.

      Comment


      • #93
        Originally posted by LightBit View Post
        I 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?
        Documentation 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.

        Yes, that is a problem. I prefer POSIX way, but that is subjective.
        POSIX is accepted as standard by many OSes.
        Linux 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


        • #94
          Originally posted by LightBit View Post
          Linus also said Linux (kernel) is bloated: http://www.theregister.co.uk/2009/09..._bloated_huge/
          Yes, because when you compare old Linux kernels to the newest one you will notice it has grown a lot! However, it's good, because it gained many drivers, features and some file systems. Newer kernels are much faster in some cases than older ones. It's bloated compared to what it was in the past, but this bloat is mainly related to package size (you still use just few percent of it) and not to parts of the kernel that are running on your box.

          Comment


          • #95
            Originally posted by kraftman View Post
            Still, the features and completeness can make a difference.
            I 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.

            Comment


            • #96
              Originally posted by kraftman View Post
              Documentation 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.
              This 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.


              Originally posted by kraftman View Post
              Linux 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.
              Yes, but they try to be as much as possible. Of course there are some missing parts.

              Comment


              • #97
                Originally posted by LightBit View Post
                This 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.
                "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.

                Yes, but they try to be as much as possible. Of course there are some missing parts.
                I 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


                • #98
                  Originally posted by LightBit View Post
                  I 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.
                  Take a look here:



                  and here:

                  Last edited by kraftman; 07 May 2012, 04:10 AM.

                  Comment


                  • #99
                    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.
                    Is it possible to overcommit physical memory (RAM + swap) without overcommiting free memory (RAM + swap)?


                    Originally posted by kraftman View Post
                    I 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.
                    If you are fully POSIX compliant, you can also "overcommit" POSIX limit. POSIX doesn't prohibits non-POSIX functions.

                    Comment


                    • I was talking about glibc (because it is being used by most of distributions). I know there are alternatives.

                      Comment

                      Working...
                      X