Branch: refs/heads/master
  Home:   https://github.com/NixOS/nixpkgs
  Commit: a5bc11f9eb70482daf559019f9b775c285defb63
      
https://github.com/NixOS/nixpkgs/commit/a5bc11f9eb70482daf559019f9b775c285defb63
  Author: aszlig <[email protected]>
  Date:   2015-12-14 (Mon, 14 Dec 2015)

  Changed paths:
    M nixos/modules/virtualisation/qemu-vm.nix
    M pkgs/build-support/vm/default.nix
    M pkgs/build-support/vm/windows/controller/default.nix

  Log Message:
  -----------
  nixos/vm-tests: Remove msize mount option

This seems to be the root cause of the random page allocation failures
and @wizeman did a very good job on not only finding the root problem
but also giving a detailed explanation of it in #10828.

Here is an excerpt:

  The problem here is that the kernel is trying to allocate a contiguous
  section of 2^7=128 pages, which is 512 KB. This is way too much:
  kernel pages tend to get fragmented over time and kernel developers
  often go to great lengths to try allocating at most only 1 contiguous
  page at a time whenever they can.

  From the error message, it looks like the culprit is unionfs, but this
  is misleading: unionfs is the name of the userspace process that was
  running when the system ran out of memory, but it wasn't unionfs who
  was allocating the memory: it was the kernel; specifically it was the
  v9fs_dir_readdir_dotl() function, which is the code for handling the
  readdir() function in the 9p filesystem (the filesystem that is used
  to share a directory structure between a qemu host and its VM).

  If you look at the code, here's what it's doing at the moment it tries
  to allocate memory:

    buflen = fid->clnt->msize - P9_IOHDRSZ;

    rdir = v9fs_alloc_rdir_buf(file, buflen);

  If you look into v9fs_alloc_rdir_buf(), you will see that it will try
  to allocate a contiguous buffer of memory (using kzalloc(), which is a
  wrapper around kmalloc()) of size buflen + 8 bytes or so.

  So in reality, this code actually allocates a buffer of size
  proportional to fid->clnt->msize. What is this msize? If you follow
  the definition of the structures, you will see that it's the
  negotiated buffer transfer size between 9p client and 9p server. On
  the client side, it can be controlled with the msize mount option.

  What this all means is that, the reason for running out of memory is
  that the code (which we can't easily change) tries to allocate a
  contiguous buffer of size more or less equal to "negotiated 9p
  protocol buffer size", which seems to be way too big (in our NixOS
  tests, at least).

After that initial finding, @lethalman tested the gnome3 gdm test
without setting the msize parameter at all and it seems to have resolved
the problem.

The reason why I'm committing this without testing against all of the
NixOS VM test is basically that I think we can only go better but not
worse than the current state.

Signed-off-by: aszlig <[email protected]>


  Commit: 6353f580f90c0fdd2b418fa853a78ec508bda2a5
      
https://github.com/NixOS/nixpkgs/commit/6353f580f90c0fdd2b418fa853a78ec508bda2a5
  Author: aszlig <[email protected]>
  Date:   2015-12-14 (Mon, 14 Dec 2015)

  Changed paths:
    M nixos/modules/virtualisation/qemu-vm.nix

  Log Message:
  -----------
  nixos/qemu-vm: Disable cache for $NIX_DISK_IMAGE

As @domenkozar noted in #10828, cache=writeback seems to do more harm
than good:

https://github.com/NixOS/nixpkgs/issues/10828#issuecomment-164426821

He has tested it using the openstack NixOS tests and found that
cache=none significantly improves startup performance.

Signed-off-by: aszlig <[email protected]>


  Commit: 00934bb90865b6ccd3b226c7d495adbf4dabc9da
      
https://github.com/NixOS/nixpkgs/commit/00934bb90865b6ccd3b226c7d495adbf4dabc9da
  Author: aszlig <[email protected]>
  Date:   2015-12-14 (Mon, 14 Dec 2015)

  Changed paths:
    M nixos/modules/testing/test-instrumentation.nix

  Log Message:
  -----------
  nixos/tests: Revert setting min_free_kbytes

This reverts commit 02b568414d509b5d06dbd95bcc0868d487ed359e.

With a5bc11f and 6353f58 in place, we really don't need this anymore.

After running about 500 VM tests on my Hydra, it still didn't improve
very much.

Signed-off-by: aszlig <[email protected]>


  Commit: 90997daab69ac708bff848c55b4f506080a9ae0f
      
https://github.com/NixOS/nixpkgs/commit/90997daab69ac708bff848c55b4f506080a9ae0f
  Author: aszlig <[email protected]>
  Date:   2015-12-14 (Mon, 14 Dec 2015)

  Changed paths:
    M nixos/modules/testing/test-instrumentation.nix
    M nixos/modules/virtualisation/qemu-vm.nix
    M pkgs/build-support/vm/default.nix
    M pkgs/build-support/vm/windows/controller/default.nix

  Log Message:
  -----------
  Merge branch 'fix-nixos-test-failures'

This fixes #10828 by removing the msize option and also disabling the
writeback cache for the root file system of the test machines.

I've tested this across 5 evaluations on my Hydra, where I run tests for
specific machine configurations:

https://headcounter.org/hydra/eval/304437?filter=tests
https://headcounter.org/hydra/eval/304438?filter=tests
https://headcounter.org/hydra/eval/304439?filter=tests
https://headcounter.org/hydra/eval/304440?filter=tests
https://headcounter.org/hydra/eval/304441?filter=tests

So to summarize on the test failures:

Eval    Test failures
304437  quake3, virtualbox
304438
304439  virtualbox
304440  virtualbox
304441

Both the quake3 and virtualbox test failures are unrelated to this merge
and I didn't have to cancel or restart any other jobs. The only jobs I
really had to cancel were the virtualbox jobs, so we no longer should
have "hanging" jobs in the queue due to page allocation failures of the
9p shares.

This is in controst to every evaluation before 304437, where I needed to
constantly restart VM tests.

Thanks a lot to @wizeman for finding the original issue and to
@domenkozar and @lethalman for testing and additional findings (such as
the issue with the cache option).


Compare: https://github.com/NixOS/nixpkgs/compare/f4756c5e7388...90997daab69a
_______________________________________________
nix-commits mailing list
[email protected]
http://lists.science.uu.nl/mailman/listinfo/nix-commits

Reply via email to