Announcement

Collapse
No announcement yet.

Docker Benchmarks: Ubuntu, Clear Linux, CentOS, Debian & Alpine

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

  • #21
    Originally posted by bug77 View Post
    It is not hard to have the kernel compiled for every architecture that's widely used (e.g. intel's Core, AMD's Bulldozer and upcoming Zen) and install the one you actually need. Unfortunately, that doesn't work well with installers or update tools in Linux. And of course, there's not much of an incentive to do that, since you can compile the kernel yourself with any optimizations you want. Or at least after a crash course into kernel's compilation and available optimizations you can.
    Techically speaking, tools are already arch-aware, there are packages tagged as i386 or i486 or i686 or x86_64 and the package system can use this info already.

    The issue is that there is no will to split x86_64 into different archs.

    Comment


    • #22
      Originally posted by starshipeleven View Post
      Note that you would need to split distros again in hard categories like 32bit/64bit, (just with "x86 cpus 2010-2012", "x86 cpus 2013-2014", "x86 cpus 2015-2016" and so on, for example)
      by "hard categories" I mean you cannot boot a disk or installer made with a specific category in a device not supporting it, or that you will have random breakage if you do (probably worse).

      Just like you can't boot a 64-bit distro on a 32bit-only processor.

      Comment


      • #23
        Originally posted by starshipeleven View Post
        Techically speaking, tools are already arch-aware, there are packages tagged as i386 or i486 or i686 or x86_64 and the package system can use this info already.

        The issue is that there is no will to split x86_64 into different archs.
        True, but what I had in mind is: are these tools capable of detecting you've changed your CPU and switch to the appropriate kernel automatically? But then again, I'm not sure how Windows handles this either.

        Comment


        • #24
          very interesting, thanks !

          Comment


          • #25
            Originally posted by bug77 View Post
            True, but what I had in mind is: are these tools capable of detecting you've changed your CPU and switch to the appropriate kernel automatically? But then again, I'm not sure how Windows handles this either.
            Since a kernel compiled for one CPU won't run properly in another CPU, this has to be dealt with by the bootloader, and you will have to keep installed a bundle of kernels.
            This is doable, GRUB can be kept compiled for max compatibility and then it will choose the best kernel for the arch it detects. Really it can do so much stuff already, this isn't even hard.

            The issue is for the rest of the userspace. You need to have copies of everything that uses instructions you might not have in another system.

            Or use a live CD to convert package arch of a system when you migrate it.

            Really, you are losing some flexibility, no way around it.

            Comment


            • #26
              Originally posted by bug77 View Post

              While we're at it, what about OSes that are usually run inside Docker containers, like CoreOS?
              It's great to see Docker benchmarked at all, but what I (and theonlydoo) mean, is standard tests don't paint a very accurate picture.
              coreos is not meant to run inside docker z.z

              and to achieve native like with docker you would have lift off some isolation and run like `--net=host --host=pid ` perform whatever i/o bench on mounted volumes and make sure paths like /tmp and /run actually have a tmpfs on them which I believe is not the default

              Comment


              • #27

                As others have pointed out, this test is pretty meaningless without the information about which OS uses which docker file system driver.
                For all tests that do significant I/O this turns out to be more a test about how that driver performs on this test.
                What is needed is at least the information which driver is used by each OS (by default).
                Otherwise, for CPU intensive test, or tests where the I/O to disk is done to a volume mounted an the host, I would not expect any major performance overhead when running tests inside a docker container.

                Comment


                • #28
                  Originally posted by untore View Post

                  coreos is not meant to run inside docker z.z
                  Yes, it is: https://bobcares.com/blog/top-5-oper...nfrastructure/

                  Comment


                  • #29
                    Originally posted by bug77 View Post
                    that article talks about the best host systems for docker.

                    " CoreOS is a production-ready operating system optimized for container hosting. "

                    emphasis mine

                    Comment


                    • #30
                      Originally posted by starshipeleven View Post
                      that article talks about the best host systems for docker.

                      " CoreOS is a production-ready operating system optimized for container hosting. "

                      emphasis mine
                      But to my knowledge, you still start with a minimal Docker image and add what you need. I could be wrong though, my knowledge about Docker is almost 100% theoretical. One more thing that's been sitting on my to do list since forever...

                      Comment

                      Working...
                      X