linux-kernel - Re: [git pull] scheduler fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1232287234.4824.43.camel@kulgan.wumi.org.au>
Date:	Mon, 19 Jan 2009 00:30:34 +1030
From:	Kevin Shanahan <kmshanah@...b.org.au>
To:	Avi Kivity <avi@...hat.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Mike Galbraith <efault@....de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	a.p.zijlstra@...llo.nl, torvalds@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [git pull] scheduler fixes

On Sun, 2009-01-18 at 11:21 +0200, Avi Kivity wrote:
> If the host load is low enough, it may be worthwhile to repeat with 
> -no-kvm.  It's significantly different from kvm (much higher cpu load, 
> and less tasks involved), but if the problem recurs, we know it's a pure 
> sched issue.

Okay I repeated the test as best I could with the standard 2.6.28 kernel
and "-no-kvm" added to the command lines of all the guests. I couldn't
repeat exactly the same test due to some problems with the guests.

- Two of the XP guests were taking a looong time to complete their
  startup and get into idle mode. I waited ~30 minutes for them to
  settle, but they were still running with 100% CPU load, so I shut them
  down.
- The two linux SMP guests would not boot unless I added "nosmp" to the
  kernel command line in grub within the guest. Screenshots of where the
  two guests got stuck booting are attached.

Here are the results of the ping test, FWIW:

--- hermes-old.wumi.org.au ping statistics ---
900 packets transmitted, 900 received, 0% packet loss, time 903042ms
rtt min/avg/max/mdev = 0.388/2.389/73.171/3.685 ms

There's probably a few too many things different with this test compared
to the previous ones, but I guess it does point to the problem being an
interaction between both the scheduler and kvm. It may also be that it
requires smp guests to be running to trigger.

Regards,
Kevin.


Download attachment "kvm-10.png" of type "image/png" (13377 bytes)

Download attachment "kvm-17.png" of type "image/png" (12538 bytes)